Security Requirements Analysis Report

Comprehensive Security Analysis with Interactive Dashboard

Generated: 2025-11-19 13:38:03 Report Version: 2.0 - Comprehensive Security Analysis

---

1. Executive Summary

This section provides a high-level overview of the security requirements analysis, presenting key findings, validation results, and an interactive dashboard for stakeholders and decision-makers. The executive summary enables rapid comprehension of the security posture, critical risks, control coverage, and compliance status without requiring detailed technical knowledge.

1.1. Purpose and Scope

Purpose

This document presents a comprehensive security requirements analysis for the proposed application, systematically mapping high-level business requirements to specific, actionable security controls aligned with multiple industry standards: OWASP Application Security Verification Standard (ASVS), NIST SP 800-53 Rev 5, and ISO 27001:2022. The analysis provides a complete security requirements specification that guides secure system design, implementation, and verification.

Scope

This analysis encompasses all functional requirements provided, delivering comprehensive coverage across multiple security domains:

• Requirements Analysis: Systematic decomposition and security-relevant extraction from business requirements
• Stakeholder Analysis: Identification of stakeholders, trust boundaries, and security responsibilities
• Threat Modeling: Systematic identification and assessment of security threats using STRIDE methodology
• Security Control Mapping: Mapping requirements to multi-standard security controls (OWASP ASVS, NIST SP 800-53, ISO 27001) with detailed implementation guidance
• Compliance Requirements: Identification of regulatory and legal compliance obligations
• Architectural Security: Security architecture recommendations and design patterns
• Implementation Planning: Prioritized, phased implementation roadmap
• Verification Strategies: Testing and validation approaches for security controls

The analysis provides both strategic guidance for security planning and tactical details for implementation teams.

1.2. Key Findings

This section summarizes the most critical results from the security requirements analysis, providing executives and stakeholders with immediate insight into the security posture and validation status.

Analysis Metrics

• Validation Score: 0.85/1.0
• Validation Status: ✅ Passed
• Analysis Iterations: 1
• Requirements Analyzed: 20

Application Summary

A web application that lets users securely upload images/PDFs of their blood test reports, uses OCR and AI to extract structured test data, identifies abnormalities, provides human-friendly summaries and longitudinal visualizations, and preserves historical health records while giving users control over privacy, consent, notifications, and exports.

The validation score reflects the quality and completeness of the security requirements across five dimensions: completeness, consistency, correctness, implementability, and alignment with business objectives. A score of 0.8 or higher indicates that the requirements are ready for implementation, while scores below this threshold may require refinement before proceeding.

1.3. Security Overview Dashboard

This interactive dashboard provides executive-level visualization of key security metrics and trends, enabling rapid assessment of the security posture through intuitive charts and data visualizations. The dashboard presents critical information across multiple dimensions: risk distribution, security control coverage, compliance status, implementation progress, and data quality metrics. For optimal viewing experience, render this document with Quarto to enable interactive chart functionality, allowing stakeholders to explore data dynamically and drill down into specific areas of interest.

Risk

Figure 1: Risk heat map showing threat distribution by likelihood and impact (1-5 scale).

Top 5 Highest Risks:

THR-001 (Critical) - Frontend Layer - Authentication & Password Recovery - Category: Spoofing - Likelihood: 4 | Impact: 4 - Description: Credential theft via phishing, reuse, or compromised local storage leading to account takeover (including abuse of password reset flows). Attackers may spoof legitimate users to access PHI and analysi

THR-004 (Critical) - Edge Layer - API Gateway/WAF - Category: Denial of Service - Likelihood: 4 | Impact: 4 - Description: Upload flood or large-file upload spikes (accidental or malicious) causing bandwidth exhaustion or queue/backlog saturation, impacting OCR/AI worker availability and overall service.

THR-006 (Critical) - Application Services - Authentication & RBAC - Category: Elevation of Privilege - Likelihood: 4 | Impact: 4 - Description: Broken access control where users can access or modify other users’ blood test data (IDOR), or escalate to admin functions via insufficient authorization checks.

THR-019 (Critical) - Application Services - APIs - Category: Information Disclosure - Likelihood: 4 | Impact: 4 - Description: APIs exposing excessive data via verbose endpoints or misconfigured filters allow attackers to enumerate or bulk-download user PHI (insecure direct object references, over-permissive list endpoints).

THR-003 (High) - Frontend Layer - File Uploads (mobile camera) - Category: Information Disclosure - Likelihood: 4 | Impact: 3 - Description: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-filled captions being uploaded and stored unintentionally, exposing PII/PHI.

Controls

Figure 2: Security control distribution by standard (OWASP, NIST, ISO 27001).

Figure 3: OWASP ASVS control distribution by verification category (V1-V14).

Figure 4: Security control priority distribution (Critical/High/Medium/Low).

Coverage Metrics:

• Total Security Controls Mapped: 74
  • OWASP ASVS: 22 controls
  • NIST SP 800-53: 30 controls
  • ISO 27001: 20 controls
• Requirements with Security Control Mapping: 90.0% (18/20)
• Average Controls per Requirement: 3.7
• Critical Controls: 25 (33.8% of total)
• Requirements with Verification: 100.0% (20/20)
• Recommended ASVS Level: L2 (Standard)

Compliance

Figure 5: Compliance status across all applicable frameworks (Red-Amber-Green rating). Shows regulatory compliance (GDPR, HIPAA, PCI-DSS, etc.) and security standards (OWASP ASVS, NIST SP 800-53, ISO 27001).

Compliance Summary:

• ⚠️ GDPR: In Progress (Next Audit: TBD)
• ⚠️ OWASP ASVS: In Progress (Next Audit: N/A)
• ⚠️ NIST SP 800-53: In Progress (Next Audit: N/A)
• ⚠️ ISO 27001: In Progress (Next Audit: N/A)

Delivery

Figure 6: Projected implementation timeline by phase and week (based on priority-based planning).

Implementation Timeline (Projected):

• Phase 1 (Critical/High): 100% projected completion (Weeks 1-8)
• Phase 2 (Medium): 100% projected completion (Weeks 9-16)
• Phase 3 (Low/Ongoing): Continuous improvement and monitoring

Note: Timeline is based on priority-based planning and assumes steady implementation progress.

Data Quality

Validation Metrics:

Overall Validation Score: ✅ 0.85/1.0

Dimension Scores:

• ⚠️ Completeness: 0.78
• ✅ Consistency: 0.90
• ✅ Correctness: 0.90
• ✅ Implementability: 0.80
• ✅ Alignment: 0.88

Figure 7: Data quality and coverage metrics.

Traceability Matrix:

• Total Requirements: 20
• Linked to Threats: 20 (100.0%)
• Mapped to Security Controls: 18 (90.0%)
• With Verification: 20 (100.0%)

Data Quality: ✅ Excellent

---

2. Requirements Understanding

This section presents a comprehensive analysis of the functional requirements, extracting security-relevant information and establishing the foundation for the security requirements specification. Understanding the functional requirements is essential for identifying security implications, data sensitivity, trust boundaries, and security-critical components. This analysis transforms business requirements into security-aware specifications that inform threat modeling, control selection, and compliance assessment.

2.1. High-Level Requirements Analysis

The following high-level functional requirements have been identified and analyzed for security implications:

1. User registration and login with multi-factor authentication and password recovery
2. User profile management with personal details and optional health metrics
3. User consent and privacy preferences management (consent capture, audit, revocation)
4. Secure upload pipeline for images and PDF blood test reports (device storage + mobile camera)
5. File format, quality, size validation, and malware scanning for uploads
6. Metadata capture for uploads (test date, laboratory name, device/time metadata)
7. Upload progress feedback and reliable completion status with resumable uploads
8. OCR and AI-based extraction of test names, values, units, and reference ranges
9. Automatic identification and flagging of abnormal values with confidence scores
10. Generation of plain-language summaries and contextual explanations for findings
11. Maintain and manage historical blood-test records with versioning and provenance
12. Time-series visualizations and charts with filters (test type, date range) and trend indicators
13. Export capability for selected data to PDF and CSV with redaction and consent checks
14. Notification system: email and in-app notifications for analysis completion and alerts for out-of-range results
15. Configurable notification preferences and escalation settings
16. Access control and role-based administration (user, clinician, admin, auditor)
17. Audit logging, monitoring, and tamper-evident trails for all sensitive operations
18. Encryption of data in transit and at rest, key management, and secure storage
19. Third-party integration and vendor risk management for AI/OCR providers and email gateways
20. Data retention, deletion (right to be forgotten), backup, and disaster recovery procedures

2.2. Detailed Requirements Breakdown

Req ID	Requirement	Business Category	Security Sensitivity	Data Classification
REQ-001	User registration and login with multi-factor auth…	Authentication	Medium	Confidential
REQ-002	User profile management capturing personal details…	User Management	High	Restricted
REQ-003	User consent and privacy preferences management in…	Security & Compliance	High	Restricted
REQ-004	Secure upload pipeline supporting images and PDFs …	Data Ingestion	High	Restricted
REQ-005	Server-side file validation for allowed formats, s…	Data Ingestion	Medium	Confidential
REQ-006	Capture and store metadata for each upload includi…	Data Management	Medium	Confidential
REQ-007	Provide upload progress, resumable uploads for lar…	User Experience	Low	Public
REQ-008	Perform OCR and AI-based structured data extractio…	AI/ML Processing	High	Restricted
REQ-009	Automatically detect and flag abnormal values rela…	Clinical Decision Support	High	Restricted
REQ-010	Generate plain-language summaries and contextual e…	Reporting & UX	Medium	Confidential
REQ-011	Persist historical blood-test records with version…	Data Management	High	Restricted
REQ-012	Provide interactive time-series visualizations and…	Visualization	Medium	Confidential
REQ-013	Allow export of selected data and reports into PDF…	Data Export	High	Restricted
REQ-014	Notify users (email and in-app) when AI analysis c…	Notifications	High	Confidential
REQ-015	Implement configurable notification preferences (c…	User Experience	Medium	Confidential
REQ-016	Role-based access control for users, clinicians, a…	Access Control	High	Restricted
REQ-017	Comprehensive audit logging and monitoring of auth…	Security & Compliance	High	Internal
REQ-018	Encrypt all sensitive data in transit (TLS) and at…	Cryptography	High	Restricted
REQ-019	Manage third-party integrations (AI/OCR, email/SMS…	Third-Party Risk	High	Restricted
REQ-020	Define data retention and deletion policies (inclu…	Data Lifecycle Management	High	Restricted

2.3. Security Context and Regulatory Obligations

Applicable regulatory and compliance obligations include HIPAA (US) for protection of PHI and required safeguards (administrative, physical, technical), GDPR (EU) for personal data protection and data subject rights (consent, access, erasure, portability) when EU residents are involved, local/state data protection laws (e.g., CCPA in CA), and applicable medical device/health software guidance if clinical decision support thresholds are used. Security frameworks and standards to apply: NIST CSF/NIST SP 800-53, ISO 27001 for ISMS, SOC 2 controls for operational security, and OWASP ASVS for web application security. Obligations include breach notification timelines, Data Processing Agreements with vendors, Data Protection Impact Assessments (DPIA) for high-risk processing (AI on health data), secure handling of cross-border transfers (standard contractual clauses or adequacy mechanisms), maintaining audit trails, encryption, access controls, and rights fulfilment (access, correction, deletion).

2.4. Assumptions

• System will be cloud-hosted on a major provider (e.g., AWS/GCP/Azure) with shared-responsibility security model.
• End users have internet access and typical modern browsers or mobile devices with camera capability.
• Third-party AI/OCR components may be used (cloud or SaaS) and must be integrated under strict DPA terms.
• Laboratory reports follow commonly used layouts and languages primarily in the target market(s); occasional manual review will be required.
• Users will provide explicit consent for processing of their blood test data and optional PII fields.
• There will be a product operations team responsible for incident response, vendor management, and compliance activities.
• Scale assumptions: initial user base modest (thousands), design should be scalable to hundreds of thousands with autoscaling and queuing for OCR/AI jobs.

2.5. Constraints

• Must comply with applicable healthcare data regulations in target jurisdictions (e.g., HIPAA, GDPR) which may restrict cross-border data flows and require specific controls.
• Integration constraints: may need to interoperate with legacy EHR systems or clinician portals via HL7/FHIR in future releases.
• Latency constraints for AI/analysis: balance between real-time user expectations and batch/queued processing for costly AI inference.
• Storage constraints: file size and retention limits to control cost; must implement retention schedules and archival tiers.
• Usability constraints: mobile camera capture must handle varied lighting and device capabilities; image pre-processing required.
• Operational constraints: budget and team competence for 24/7 monitoring and incident response; must plan for SOC/ISO readiness if demanded by enterprise customers.
• Security constraints: key management separation, limited access to production data for developers, and requirement to anonymize/sanitize logs to avoid PHI leakage.
• Legal constraints: requirement to have Data Processing Agreements (DPAs) with any AI/OCR provider and email/SMS vendors; some vendors may be disallowed in certain jurisdictions.
• Export constraints: PDF/CSV exports must include redaction controls and must honor user consent before allowing third-party sharing.
• Retention/deletion constraints: must implement secure deletion and ensure backups and logs conform to deletion/retention policy to satisfy ‘right to be forgotten’.

---

3. Stakeholder Analysis

This section identifies and analyzes all stakeholders involved in or affected by the system, including users, administrators, external partners, and regulatory bodies. Stakeholder analysis establishes trust boundaries, defines security responsibilities, and identifies potential security concerns from different stakeholder perspectives. Understanding stakeholder relationships and trust boundaries is critical for designing appropriate access controls, authentication mechanisms, and data protection measures.

3.1. Identified Stakeholders and User Personas

Role	Privilege Level	Trust Level	Key Security Concerns
Patient	User	Partially Trusted	Unauthorized access to personal health records, identity theft through compromised credentials, data integrity during upload.
Healthcare Provider	User	Trusted	Data breach during patient consultations, phishing attacks targeting credentials, unauthorized access to sensitive patient data.
System Administrator	Admin	Trusted	Privilege escalation by malicious insiders, account compromise leading to system-wide access, misconfiguration of security settings.
Third-Party AI/OCR Provider	Service Account	Partially Trusted	Insecure API integration exposing patient data, data leakage during extraction processes, lack of proper authentication mechanisms.
Notification Service (Email/SMS)	Service Account	Partially Trusted	Exposure of notifications to unauthorized parties, failure to deliver sensitive alerts, data integrity of notification content.
Identity Provider	Service Account	Trusted	Credential theft, unauthorized access through compromised identity services, risks of single sign-on attacks.

3.2. Trust Model

Trust boundaries are established at the user interface, backend server, and database levels. Security mechanisms enforcing boundaries include user authentication via email/password and optional multi-factor authentication (MFA), role-based access control (RBAC) to ensure users can only access data and functionalities pertinent to their roles, and network segmentation to mitigate risks of unauthorized access. Patients can only access their personal medical records and upload their blood tests; Healthcare Providers have access to patient records they are actively treating and can view the analytical outputs; System Administrators have access to comprehensive management functions, including user management and system settings. The principle of least privilege is implemented by granting users the minimum access necessary to perform their responsibilities, thereby reducing the risk of data exposure and privilege escalation. For instance, while a patient may view their own test results, they cannot access other patients’ data; similarly, Healthcare Providers can only access records of patients they are treating, which helps maintain strict confidentiality and compliance with health regulations.

---

4. System Architecture Analysis

4.1. Architectural Overview

The system is a cloud-hosted web application composed of a user-facing frontend (web SPA and mobile apps) behind an edge layer (CDN, WAF, API gateway) that authenticates and routes requests to backend application services. The backend orchestrates upload/validation, queued OCR/AI processing, analysis and summarization, notification and audit services, and persists encrypted files and structured results in an encrypted object store and relational database. Identity, RBAC, audit logging, and key management services enforce security and compliance, while external vendors (AI/OCR providers, email/SMS gateways, identity providers) are integrated under strict DPAs. Components interact via authenticated TLS channels and queued jobs to support scalable asynchronous processing and maintainable audit trails.

4.2. Architecture Diagram

4.3. Component Breakdown

Component	Responsibility	Security Criticality	External Dependencies
Frontend Layer	Provides user interfaces (web SPA and mo…	Medium	CDN/WAF (cloud provider), External Identity Providers (optional)
Edge Layer	Protects and routes traffic using CDN, W…	High	Cloud CDN/WAF provider, API Gateway service
Application Services	Core backend that handles authentication…	Critical	Third-party AI/OCR providers, Email/SMS gateways
Data Storage	Secure, encrypted storage for raw files,…	Critical	Cloud object storage, Managed relational database
Identity & Security Services	Provides authentication, MFA, RBAC, cons…	Critical	External IdP for federated auth (optional), KMS provider
External Services	Third-party integrations used for OCR/AI…	High	AI/OCR SaaS or cloud ML APIs, Email/SMS gateway providers

4.4. Data Flow Analysis

Users upload images/PDFs via the Frontend which transmits files over TLS to the Edge Layer (CDN/API gateway). The Upload Service validates format/quality and stores files in the encrypted object store and enqueues a job in the Job Queue. OCR/AI Workers pull jobs, call internal or third-party AI/OCR, produce structured test records with confidence scores, and push results to Analysis service. Analysis flags abnormalities, generates summaries, and persists structured data in the encrypted relational DB and provenance metadata in the audit store. Notifications are emitted via the Notification Service (in-app and email/SMS). Exports are rendered from persisted structured data and object store files. KMS manages keys for encryption; audit logs and immutable stores preserve tamper-evident trails. Backups and retention policies archive data to cold storage and support secure deletion/erasure workflows.

4.5. Attack Surface Analysis

Major entry points: 1) Public web/mobile UI (High) — risks include XSS, CSRF, insecure storage of tokens, and file-based attacks via uploads. Mitigations: OWASP ASVS controls, CSP, secure cookie flags, client-side encryption options, robust input validation and malware scanning. 2) File upload API (High) — accepts PHI and potentially malicious files. Mitigations: authenticated endpoints, file-type/size/quality validation, sandboxed processing, virus scanning, content disarm & reconstruction, throttling and resumable upload auth. 3) Backend API endpoints (High) — exposed CRUD and export functions. Mitigations: strict RBAC, parameterized queries, input validation, rate limiting, mTLS for inter-service calls, strong monitoring and WAF. 4) Third-party AI/OCR integration (Medium-High) — data exfiltration and compliance risk. Mitigations: minimal redaction before sending, DPAs, encryption in transit, allow-listing, and differential privacy or on-premise options where required. 5) Notification channels (Email/SMS) (Medium) — risk of PHI leakage in notifications. Mitigations: redaction, user-configurable notification preferences, avoid PHI in subject lines, use secure email gateways. 6) Admin/Operations consoles and logs (High) — insider and credential compromise risk. Mitigations: MFA, least privilege, JIT access, separation of environments, and immutable audit logging. 7) Identity federation endpoints (Medium) — token replay or misconfiguration risks. Mitigations: use trusted IdPs, rotate keys, validate tokens, and restrict scopes. Overall risk management: encrypt data at rest and in transit, rigorous vendor management, continuous monitoring/alerting, regular pen-tests, and compliance-driven controls (HIPAA/GDPR) to reduce residual risk.

---

5. Threat Modeling

This section presents a comprehensive threat analysis of the system architecture and functional requirements. Threat modeling systematically identifies potential security vulnerabilities and attack vectors, enabling proactive risk mitigation through the application of appropriate security controls.

5.1. Threat Modeling Methodology

This analysis employs the STRIDE threat modeling methodology, a systematic framework developed by Microsoft for identifying security threats across six categories:

• Spoofing Identity: Threats involving impersonation of users or systems
• Tampering with Data: Threats involving unauthorized modification of data or system components
• Repudiation: Threats where users deny performing actions (lack of non-repudiation)
• Information Disclosure: Threats involving unauthorized access to sensitive information
• Denial of Service: Threats causing disruption or unavailability of system services
• Elevation of Privilege: Threats allowing unauthorized access to privileged functions

For each identified threat, the analysis evaluates likelihood (attack complexity and exposure) and impact (potential damage to confidentiality, integrity, or availability) to determine overall risk level. The methodology ensures comprehensive coverage of security concerns across all system components and interfaces.

5.2. Threat Analysis and Risk Assessment

5.2.1. Threat Overview

The following table provides a quick reference of all identified threats. Detailed analysis including descriptions, mitigation strategies, and residual risk assessment (where available) is provided in the section below.

Threat ID	Component	Category	Risk Level	Likelihood	Impact
THR-001	Frontend Layer - Authentication & Password Recovery	Spoofing	Critical	High	High
THR-004	Edge Layer - API Gateway/WAF	Denial of Service	Critical	High	High
THR-006	Application Services - Authentication & RBAC	Elevation of Privilege	Critical	High	High
THR-019	Application Services - APIs	Information Disclosure	Critical	High	High
THR-003	Frontend Layer - File Uploads (mobile camera)	Information Disclosure	High	High	Medium
THR-005	Edge Layer - TLS Termination / Gateway	Spoofing	High	Medium	High
THR-007	Application Services - Input Handling and OCR Pipeline	Tampering	High	Medium	High
THR-008	Application Services - OCR/AI Integration (Third-party)	Information Disclosure	High	Medium	High
THR-009	Application Services - Analysis Results & Summaries	Tampering	High	Medium	High
THR-011	Data Storage - Object Store (encrypted files)	Information Disclosure	High	Medium	High
THR-012	Data Storage - Relational Database	Tampering	High	Medium	High
THR-013	Data Storage - Backups & Archives	Information Disclosure	High	Medium	High
THR-014	Identity & Security Services - External IdP	Spoofing	High	Medium	High
THR-015	Identity & Security Services - Key Management Service (KMS)	Information Disclosure	High	Low	High
THR-016	Application Services - Notifications & Email/SMS Gateways	Information Disclosure	High	High	Medium
THR-017	External Services - AI/OCR Provider	Tampering	High	Low	High
THR-020	Application Services - Input Validation (Web APIs)	Tampering	High	Medium	High
THR-022	Application Services - Audit Logging & Monitoring	Repudiation	High	Medium	High
THR-025	Cloud Infrastructure - IAM & Misconfiguration	Elevation of Privilege	High	Medium	High
THR-026	Application Services - SSRF and SSRF to Internal Services (AI Vendor endpoints)	Tampering/Information Disclosure	High	Medium	High
THR-028	Application Services / Data Storage - Consent & Privacy Preferences	Repudiation/Information Disclosure	High	Medium	High
THR-002	Frontend Layer - Web SPA / Mobile App	Tampering	Medium	Medium	Medium
THR-010	Application Services - Message Queue / Job Orchestration	Denial of Service	Medium	Medium	Medium
THR-018	External Services - Email/SMS Provider	Repudiation	Medium	Medium	Medium
THR-021	Frontend & Edge - CSRF & XSS	Tampering/Information Disclosure	Medium	Medium	Medium
THR-023	Application Services - Export (PDF/CSV) Generation	Information Disclosure	Medium	Medium	Medium
THR-024	External Services - Telemetry & Vendor Logs	Information Disclosure	Medium	Medium	Medium
THR-027	Application Services - Model & Data Poisoning	Tampering	Medium	Low	Medium

Total Threats Identified: 28

5.2.2. Detailed Threat Analysis

This section provides comprehensive analysis of each identified threat, including descriptions, mitigation strategies, and residual risk assessment (where controls have been evaluated). Threats are organized by risk level for prioritized review.

Critical Risk Threats

THR-001 - Frontend Layer - Authentication & Password Recovery

• Category: Spoofing
• Likelihood: High | Impact: High
• Initial Risk Level: Critical
• Description: Credential theft via phishing, reuse, or compromised local storage leading to account takeover (including abuse of password reset flows). Attackers may spoof legitimate users to access PHI and analysis results.
• Mitigation Strategy: Enforce strong password policies, rate-limit password resets, require MFA (preferably hardware or TOTP), implement phishing-resistant flows, secure session cookies (HttpOnly, Secure, SameSite=strict), avoid storing credentials in local storage, implement account lockout & notification on suspicious activity, monitor for credential stuffing and anomalous logins.
• Controls Applied: MFA enforcement, TLS 1.2+, Secure cookie flags, Password complexity & rate limiting, Auth anomaly detection
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-004 - Edge Layer - API Gateway/WAF

• Category: Denial of Service
• Likelihood: High | Impact: High
• Initial Risk Level: Critical
• Description: Upload flood or large-file upload spikes (accidental or malicious) causing bandwidth exhaustion or queue/backlog saturation, impacting OCR/AI worker availability and overall service.
• Mitigation Strategy: Enforce rate limits per IP/user, file size limits, upload quotas, CAPTCHA for suspicious flows, upload throttling and pre-signed upload tokens with short TTLs, autoscaling with backpressure, charge-rate limiting on heavy AI usage.
• Controls Applied: API rate limiting, WAF rules, Pre-signed uploads, Autoscaling + queue backpressure
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-006 - Application Services - Authentication & RBAC

• Category: Elevation of Privilege
• Likelihood: High | Impact: High
• Initial Risk Level: Critical
• Description: Broken access control where users can access or modify other users’ blood test data (IDOR), or escalate to admin functions via insufficient authorization checks.
• Mitigation Strategy: Implement least-privilege RBAC with server-side authorization checks on every request, use strong resource-based ACLs, adopt attribute-based access control for sensitive operations, perform automated access control tests and code reviews, enforce separation of duties for admin functions.
• Controls Applied: Server-side RBAC enforcement, Access control testing
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ❌ Unacceptable

THR-019 - Application Services - APIs

• Category: Information Disclosure
• Likelihood: High | Impact: High
• Initial Risk Level: Critical
• Description: APIs exposing excessive data via verbose endpoints or misconfigured filters allow attackers to enumerate or bulk-download user PHI (insecure direct object references, over-permissive list endpoints).
• Mitigation Strategy: Implement pagination, rate limits, strict server-side authorization, field-level filtering, avoid returning full PHI in lists, require scopes for bulk export, enforce export approvals and audit before large exports.
• Controls Applied: Pagination & rate limits, Field-level authorization, Export approval workflow
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ❌ Unacceptable

High Risk Threats

THR-003 - Frontend Layer - File Uploads (mobile camera)

• Category: Information Disclosure
• Likelihood: High | Impact: Medium
• Initial Risk Level: High
• Description: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-filled captions being uploaded and stored unintentionally, exposing PII/PHI.
• Mitigation Strategy: Strip EXIF/metadata on client or immediately on ingest server; present clear consent & preview showing redactions; apply automatic PII detection; educate users on metadata; minimize metadata persisted.
• Controls Applied: Metadata stripping on ingest, User consent screens
• Control Effectiveness: High
• Residual Risk Level: Medium
• Status: ⚠️ Requires Review

THR-005 - Edge Layer - TLS Termination / Gateway

• Category: Spoofing
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: TLS termination misconfiguration or acceptance of weak ciphers allows man-in-the-middle (MITM) attacks that can intercept authentication tokens or PHI in transit.
• Mitigation Strategy: Enforce TLS 1.2+ (prefer 1.3), disable weak ciphers/SSL, enable HSTS, mutual TLS for service-to-service where appropriate, certificate pinning in mobile clients, regular certificate monitoring and automated rotation.
• Controls Applied: TLS 1.3 enforcement, HSTS, Certificate management automation
• Control Effectiveness: High
• Residual Risk Level: Medium
• Status: ⚠️ Requires Review

THR-007 - Application Services - Input Handling and OCR Pipeline

• Category: Tampering
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed fonts, or OCI payloads exploit parsing libraries causing arbitrary code execution or tampering with processing results.
• Mitigation Strategy: Perform strict file type validation, sandbox processing (container isolation, seccomp), run OCR/AI tasks in isolated least-privilege environments, use up-to-date libraries, do content sanitization and enforce time/memory limits, use malware scanning for uploads.
• Controls Applied: Sandboxed processing, File validation & malware scanning
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-008 - Application Services - OCR/AI Integration (Third-party)

• Category: Information Disclosure
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Sensitive PHI sent to third-party AI/OCR providers without sufficient minimization or redaction leads to data exposure, provider misuse, or non-compliant processing.
• Mitigation Strategy: Minimize data sent (send redacted images or extracted text only as needed), use DPAs, choose providers with adequate certifications, implement encryption in transit and at-rest, use on-premise/self-hosted inference or private VPC endpoints where possible, apply tokenization or anonymization before sending, maintain audit trails of data shared.
• Controls Applied: DPA contracts, Data minimization, Private network integration with vendors
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-009 - Application Services - Analysis Results & Summaries

• Category: Tampering
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Attackers modify stored analysis results or summaries (either in transit or at rest) to change medical interpretations, causing user harm or misleading clinicians.
• Mitigation Strategy: Sign analysis outputs (digital signatures), store immutable audit logs, enforce strict RBAC for editing results, apply integrity checks and versioning, perform hashing of stored artifacts with KMS-managed keys.
• Controls Applied: Object and DB encryption + integrity checks, Immutable audit logs, RBAC
• Control Effectiveness: High
• Residual Risk Level: Medium
• Status: ⚠️ Requires Review

THR-011 - Data Storage - Object Store (encrypted files)

• Category: Information Disclosure
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Misconfigured object storage ACLs or public buckets accidentally expose raw PHI (images/PDFs) to the internet or other tenants.
• Mitigation Strategy: Enforce private-by-default buckets, block public ACLs, use VPC endpoints, require signed URL with short TTL for access, encrypt objects with KMS, alert on ACL changes, and run periodic configuration scans.
• Controls Applied: Private buckets, KMS encryption, Signed URLs
• Control Effectiveness: High
• Residual Risk Level: Medium
• Status: ⚠️ Requires Review

THR-012 - Data Storage - Relational Database

• Category: Tampering
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Unauthorized modification of structured lab results, user profiles, or retention settings via SQL injection or improper DB permissions altering PHI or audit records.
• Mitigation Strategy: Use parameterized queries/ORMs, input validation, least-privilege DB accounts, separation of duties, DB activity monitoring, and regular vulnerability scanning and code review. Harden DB network access using private subnets.
• Controls Applied: Parameterized queries, DB network isolation, DB activity monitoring
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-013 - Data Storage - Backups & Archives

• Category: Information Disclosure
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Backups containing PHI are retained beyond policy or stored unencrypted offsite, leading to data leaks during breach or vendor failure.
• Mitigation Strategy: Encrypt backups with KMS-managed keys, enforce backup retention policies, perform secure deletion/overwriting, restrict access to backup keys, and include backup verification and access logging.
• Controls Applied: Encrypted backups, Retention and deletion controls, Access logging
• Control Effectiveness: High
• Residual Risk Level: Medium
• Status: ⚠️ Requires Review

THR-014 - Identity & Security Services - External IdP

• Category: Spoofing
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Compromise or misconfiguration of a federated identity provider leads to spoofed tokens, allowing unauthorized access to user accounts and PHI.
• Mitigation Strategy: Prefer enterprise-grade IdPs with strong security posture, validate tokens (signature, issuer, audience, nonce), implement token revocation and short-lived tokens, adopt SCIM provisioning controls, and monitor IdP trust relationships and metadata changes.
• Controls Applied: Token validation, Short token TTL, IdP monitoring
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-015 - Identity & Security Services - Key Management Service (KMS)

• Category: Information Disclosure
• Likelihood: Low | Impact: High
• Initial Risk Level: High
• Description: Compromise or mismanagement of encryption keys leads to decryption of PHI at rest and exposure of historical records and backups.
• Mitigation Strategy: Use managed KMS with HSM-backed keys, enforce strict IAM for key admins, rotate keys periodically, use envelope encryption, separate encryption duties from application admins, monitor key usage and configure key policy with least privilege.
• Controls Applied: Managed KMS/HSM, Key rotation and separation of duties, Key usage logging
• Control Effectiveness: High
• Residual Risk Level: Medium
• Status: ⚠️ Requires Review

THR-016 - Application Services - Notifications & Email/SMS Gateways

• Category: Information Disclosure
• Likelihood: High | Impact: Medium
• Initial Risk Level: High
• Description: Notification payloads (email/SMS) contain PHI or links that leak PHI via insecure channels, interception, or if phone/email is compromised; SMS phishing risk increases if content is not carefully designed.
• Mitigation Strategy: Avoid including PHI in notifications; send minimal, non-sensitive alerts prompting app login to view results, use secure in-app notifications for PHI, offer opt-in/opt-out controls, use encrypted email if PHI must be included, and ensure vendor contracts enforce confidentiality.
• Controls Applied: Notification content policy, In-app encrypted notifications, DPA with notification vendors
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-017 - External Services - AI/OCR Provider

• Category: Tampering
• Likelihood: Low | Impact: High
• Initial Risk Level: High
• Description: Malicious or compromised third-party model alters extracted lab values or reference ranges, resulting in incorrect analysis or false alerts.
• Mitigation Strategy: Validate vendor outputs through sampling and test datasets, implement output validation rules and plausibility checks, keep an independent verification layer or fallback model, maintain vendor diversity, and include SLA clauses for model integrity.
• Controls Applied: Output validation & plausibility checks, Vendor SLAs and diversity
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-020 - Application Services - Input Validation (Web APIs)

• Category: Tampering
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Injection attacks (SQL, NoSQL, OS, command) via unvalidated fields (e.g., lab names, date fields, file metadata) enabling data compromise or lateral movement.
• Mitigation Strategy: Use parameterized queries or ORM, strict schema validation, input sanitization, WAF tuned for injection detection, and security-focused code reviews and fuzz testing.
• Controls Applied: Parameterized queries/ORM, Input schema validation, WAF
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-022 - Application Services - Audit Logging & Monitoring

• Category: Repudiation
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Insufficient, mutable, or incomplete audit logs prevent detection of malicious actions or deny accountability (e.g., missing log entries for data exports, consent changes).
• Mitigation Strategy: Implement immutable append-only logs, forward logs to a hardened SIEM, ensure logs contain user, timestamp, and context, protect log integrity with KMS-backed signing, and monitor/alert for suspicious patterns.
• Controls Applied: Immutable audit logs, SIEM integration, Log integrity checks
• Control Effectiveness: High
• Residual Risk Level: Medium
• Status: ⚠️ Requires Review

THR-025 - Cloud Infrastructure - IAM & Misconfiguration

• Category: Elevation of Privilege
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Over-permissive IAM roles or misconfigured cloud services permit lateral movement, privilege escalation, or data access across resources (e.g., storage read access by compute instances that shouldn’t have it).
• Mitigation Strategy: Apply least privilege, regularly audit IAM policies, use role-based access controls with separation of duties, implement resource-level policies, employ cloud configuration scanning (CSPM), and enforce ephemeral credentials for services.
• Controls Applied: Least-privilege IAM, CSPM scanning, Separation of duties
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

THR-026 - Application Services - SSRF and SSRF to Internal Services (AI Vendor endpoints)

• Category: Tampering/Information Disclosure
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Server-side request forgery where attackers induce the backend to make requests to internal metadata, KMS endpoints, or vendor APIs to leak sensitive data or access internal services.
• Mitigation Strategy: Validate and whitelist outbound URLs, restrict outbound egress with network controls and VPC service endpoints, perform internal request authorization, and sanitize all user-controllable URLs.
• Controls Applied: Egress filtering, URL allow-listing
• Control Effectiveness: High
• Residual Risk Level: Medium
• Status: ⚠️ Requires Review

THR-028 - Application Services / Data Storage - Consent & Privacy Preferences

• Category: Repudiation/Information Disclosure
• Likelihood: Medium | Impact: High
• Initial Risk Level: High
• Description: Failure to correctly enforce user consent and privacy preferences (e.g., continued sharing to vendors after revocation) leads to non-compliant data processing and legal exposure.
• Mitigation Strategy: Store immutable consent records, check consent before any export or vendor call, provide user-facing controls and audit trails, implement consent propagation to vendors, and automate revocation enforcement with job quarantining.
• Controls Applied: Consent records & enforcement, Vendor revocation workflows
• Control Effectiveness: Medium
• Residual Risk Level: High
• Status: ⚠️ Requires Review

Medium Risk Threats

THR-002 - Frontend Layer - Web SPA / Mobile App

• Category: Tampering
• Likelihood: Medium | Impact: Medium
• Initial Risk Level: Medium
• Description: Client-side script manipulation (malicious browser extensions, XSS, or compromised bundle serving) that modifies UI to exfiltrate input data or change upload metadata before submission.
• Mitigation Strategy: Ensure Content Security Policy (CSP), subresource integrity (SRI) for static assets, minimize inline JS, sign mobile app builds, use code obfuscation and app attestation (e.g., SafetyNet/DeviceCheck), validate all data server-side, and protect CDN origin/integrity.
• Controls Applied: CSP, SRI, Server-side validation, App build signing and attestation
• Control Effectiveness: Medium
• Residual Risk Level: Low
• Status: ⚠️ Requires Review

THR-010 - Application Services - Message Queue / Job Orchestration

• Category: Denial of Service
• Likelihood: Medium | Impact: Medium
• Initial Risk Level: Medium
• Description: Job queue exhaustion or poisoning via crafted messages causing worker crashes or processing of malicious tasks, interrupting AI pipelines and delaying analyses.
• Mitigation Strategy: Authenticate and validate queued messages, set strict size and schema validation for queue payloads, use dead-letter queues, rate-limit producer APIs, throttle jobs per-user, and monitor queue lengths with alerting and autoscaling.
• Controls Applied: Message validation, Dead-letter queues, Queue rate limiting
• Control Effectiveness: Medium
• Residual Risk Level: Low
• Status: ⚠️ Requires Review

THR-018 - External Services - Email/SMS Provider

• Category: Repudiation
• Likelihood: Medium | Impact: Medium
• Initial Risk Level: Medium
• Description: Insufficient logging or proof of delivery leading to disputes about whether a user was notified about critical abnormal results (non-repudiation failure).
• Mitigation Strategy: Keep signed delivery receipts, store notification audit logs with timestamps and content hashes, integrate provider webhooks for delivery status, and retain logs immutable for compliance periods.
• Controls Applied: Notification delivery logging, Immutable audit storage
• Control Effectiveness: High
• Residual Risk Level: Low
• Status: ⚠️ Requires Review

THR-021 - Frontend & Edge - CSRF & XSS

• Category: Tampering/Information Disclosure
• Likelihood: Medium | Impact: Medium
• Initial Risk Level: Medium
• Description: Cross-site scripting allows attackers to capture session tokens or perform actions on behalf of users; CSRF causes unauthorized actions (e.g., changing notification preferences or uploading malicious files).
• Mitigation Strategy: Use anti-CSRF tokens, SameSite cookies, strict input/output encoding, CSP, sanitize user-generated content, adopt secure frameworks and perform periodic frontend security testing.
• Controls Applied: CSP, Anti-CSRF tokens, Output encoding
• Control Effectiveness: High
• Residual Risk Level: Low
• Status: ✅ Accepted

THR-023 - Application Services - Export (PDF/CSV) Generation

• Category: Information Disclosure
• Likelihood: Medium | Impact: Medium
• Initial Risk Level: Medium
• Description: Exports containing PHI are generated with insecure filenames or stored in locations with weak permissions, or links are shared without authentication, enabling data leakage.
• Mitigation Strategy: Require re-authentication or MFA for export, generate exports on-demand with short-lived signed URLs, sanitize filenames, restrict export storage ACLs, and log exports for audit.
• Controls Applied: Signed, short-lived export URLs, Re-authentication for exports
• Control Effectiveness: High
• Residual Risk Level: Low
• Status: ✅ Accepted

THR-024 - External Services - Telemetry & Vendor Logs

• Category: Information Disclosure
• Likelihood: Medium | Impact: Medium
• Initial Risk Level: Medium
• Description: Debugging logs, telemetry or metrics sent to third-party analytics vendors inadvertently contain PHI (e.g., test values, user IDs) and are retained by vendors.
• Mitigation Strategy: Apply strict data minimization for telemetry, scrub PHI before sending, use hashing or tokenization for identifiers, review vendor retention policies, and include DPAs restricting usage.
• Controls Applied: Telemetry scrubbing, DPA with analytics vendors
• Control Effectiveness: High
• Residual Risk Level: Low
• Status: ✅ Accepted

THR-027 - Application Services - Model & Data Poisoning

• Category: Tampering
• Likelihood: Low | Impact: Medium
• Initial Risk Level: Medium
• Description: Attackers submit crafted reports to poison training or model adaptation pipelines (if models re-train on user data), degrading model accuracy or causing harmful inferences.
• Mitigation Strategy: Avoid using raw user data to retrain models without strong vetting, use robust training datasets, apply anomaly detection on training inputs, maintain segregated training environments, and verify model behavior after updates.
• Controls Applied: Training data vetting, Anomaly detection on inputs
• Control Effectiveness: Medium
• Residual Risk Level: Low
• Status: ⚠️ Requires Review

Risk Reduction Summary:

• Critical Risk Reduction: 4 threats reduced from Critical to lower levels
• High Risk Reduction: 8 threats reduced from High to lower levels
• Residual Risk Distribution: 13 threats remain at Critical/High level

5.3. Risk Summary

The most critical threats are those that enable unauthorized access to PHI (THR-001 credential theft, THR-006 broken RBAC/privilege escalation, THR-019 excessive API data exposure), large-scale data leakage through misconfigured storage or third-party processing (THR-011 public buckets, THR-008 OCR/AI provider disclosure), and service availability or processing reliability issues (THR-004 upload/processing DoS, THR-010 queue exhaustion). Key attack vectors include authentication endpoints and password recovery, public-facing upload APIs, third-party integration endpoints (AI/OCR and notification providers), and misconfigured cloud IAM/storage. Priority areas: enforce strong authentication (MFA, token hygiene), rigorous server-side authorization and least-privilege IAM, robust input validation and sandboxing for file processing, strict data minimization and DPAs for external vendors, secure storage configurations with KMS-managed encryption, comprehensive audit logging and immutable logs, and network-level protections (WAF, rate limiting, egress whitelists). Overall risk posture is elevated due to sensitive PHI handling and multiple high-impact threat scenarios; mitigations already present in architecture (edge WAF/API gateway, KMS, DPAs) reduce but do not eliminate risk. Immediate remediation should focus on access control hardening, secure upload/processing sandboxes, third-party data flow minimization and contractual safeguards, and hardening object and backup storage configurations.

---

6. Multi-Standard Security Requirements Mapping

This section maps each functional requirement to specific security controls from multiple industry standards: OWASP Application Security Verification Standard (ASVS), NIST SP 800-53 Rev 5, and ISO 27001:2022. This multi-standard approach provides comprehensive coverage across application-level, enterprise-level, and organizational-level security domains:

• OWASP ASVS: Application-level security controls (code, APIs, authentication, session management)
• NIST SP 800-53: Enterprise security controls (governance, risk management, incident response)
• ISO 27001: Information security management controls (policies, procedures, organizational controls)

Requirements are prioritized based on risk assessment and compliance needs, with controls selected from the most appropriate standard(s) for each requirement type.

6.1. Recommended ASVS Compliance Level

Recommended Level: L2

Level 2: Standard

Recommended for most production applications. Provides comprehensive security coverage suitable for applications handling sensitive data or operating in regulated environments. Includes controls for authentication, authorization, data protection, and secure communications.

The recommendation considers factors such as:

• Data sensitivity and classification levels
• Regulatory and compliance requirements (GDPR, HIPAA, PCI-DSS, etc.)
• Threat landscape and risk assessment from threat modeling
• Business criticality and potential impact of security incidents

All security controls referenced in this document align with this recommended compliance level.

6.2. Requirements Mapping

This section maps each high-level requirement to specific security controls from multiple standards (OWASP ASVS, NIST SP 800-53, ISO 27001) with detailed descriptions, relevance explanations, and integration guidance. Controls are grouped by standard for clarity.

6.2.1. R1: User registration and login with multi-factor authentication and password recovery

ISO 27001:2022 Controls

A.9.4.2

Requirement: Where required by the access control policy, access to systems and applications should be controlled by secure log-on procedures.

Relevance: Mandates secure log-on procedures that encompass password policies, MFA, and account recovery controls as required by access policy—supporting secure registration and login.

Integration Tips: Define and enforce secure log-on procedures in policy, including MFA, minimum password strength, and account lockout thresholds; ensure procedures are implemented and communicated to users.

Verification Method: Review access control policy and log-on procedure documents; test implementation against policy requirements and interview administrators.

Priority: High

A.9.2.3

Requirement: The allocation and use of privileged access rights should be restricted and controlled.

Relevance: Applies to management of privileged accounts generated during registration or administrative onboarding, ensuring stricter authentication and recovery for powerful accounts.

Integration Tips: Apply stricter MFA and review processes for privileged account issuance; maintain records of privileged accounts and enforce periodic review.

Verification Method: Audit privileged account lists, verify MFA enforcement, and check records of privileged access assignment and reviews.

Priority: High

6.2.2. R2: User profile management with personal details and optional health metrics

ISO 27001:2022 Controls

A.18.1.4

Requirement: Privacy and protection of personally identifiable information should be ensured as required in relevant legislation and regulation.

Relevance: Directly addresses protection of PII and health-related data stored in user profiles, ensuring compliance with privacy laws for personal and health metrics. It establishes a compliance requirement that covers handling, storage, and access to sensitive personal data.

Integration Tips: Perform DPIAs where necessary, store health metrics with appropriate classification and controls, and limit collection to necessary fields. Implement consent capture for health data and document legal basis for processing.

Verification Method: Review DPIAs, data inventories, and consent records; check that storage and access controls align with classifications and legal requirements.

Priority: Critical

6.2.3. R3: User consent and privacy preferences management (consent capture, audit, revocation)

ISO 27001:2022 Controls

A.18.1.4

Requirement: Privacy and protection of personally identifiable information should be ensured as required in relevant legislation and regulation.

Relevance: Establishes the requirement to protect PII and comply with privacy legislation, which includes consent capture, retention, and revocation obligations for user preferences. It underpins legal compliance for consent mechanisms.

Integration Tips: Implement consent capture flows that record purpose, timestamp, and scope; retain consent records securely and provide revocation UI. Map consent retention periods to legal obligations.

Verification Method: Review consent records, retention policies, and UI for revocation; confirm logs capture consent events and that privacy notices are available.

Priority: Critical

6.2.4. R4: Secure upload pipeline for images and PDF blood test reports (device storage + mobile camera)

ISO 27001:2022 Controls

A.12.2.1

Requirement: Information systems should be protected against malware and appropriate detection, prevention and recovery controls should be implemented.

Relevance: Complementary requirement to ensure systems processing uploads have operational anti-malware controls and recovery procedures.

Integration Tips: Apply organizational anti-malware policies to upload-handling servers, ensure patching and endpoint protection, and define recovery procedures for infected files.

Verification Method: Review malware controls, patch and AV reports, and test recovery procedures with simulated infections.

Priority: High

6.2.5. R5: File format, quality, size validation, and malware scanning for uploads

6.2.6. R6: Metadata capture for uploads (test date, laboratory name, device/time metadata)

ISO 27001:2022 Controls

A.12.4.1

Requirement: Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed.

Relevance: Requires event logging including user activities and security events—applies to uploads where device/time metadata and other provenance details should be logged and reviewed.

Integration Tips: Implement logging for upload events, include device and laboratory metadata, configure log retention and periodic review processes, and secure log storage.

Verification Method: Verify logs contain upload metadata, review log retention settings, and sample periodic reviews for anomalies.

Priority: Medium

6.2.7. R7: Upload progress feedback and reliable completion status with resumable uploads

ISO 27001:2022 Controls

A.12.3.1

Requirement: Backup copies of information, software, and systems necessary for business continuity should be established and tested.

Relevance: Requires backups that help ensure upload reliability and completion status are recoverable in case of failures, contributing to resumable upload robustness.

Integration Tips: Ensure upload state and partially uploaded files are included in backup policies, and test restoration procedures to resume uploads or verify completion.

Verification Method: Inspect backup configurations and run restoration tests for upload state data; confirm procedures for resuming uploads after recovery.

Priority: Medium

6.2.8. R8: OCR and AI-based extraction of test names, values, units, and reference ranges

ISO 27001:2022 Controls

A.15.1.1

Requirement: Information security requirements for mitigating the risks associated with supplier’s access to the organization’s assets should be established and agreed with suppliers.

Relevance: Requires establishing and agreeing security requirements with suppliers, including OCR/AI vendors handling extracted health data.

Integration Tips: Include security and privacy controls in supplier contracts, define data handling restrictions and audit rights, and monitor supplier compliance.

Verification Method: Inspect supplier contracts for security clauses, review supplier audit results, and confirm monitoring activities.

Priority: High

6.2.9. R9: Automatic identification and flagging of abnormal values with confidence scores

ISO 27001:2022 Controls

A.12.4.3

Requirement: Administrator and operator activities should be logged, including events that could reflect abnormal system behavior.

Relevance: Supports logging of abnormal detections and administrative activities related to thresholds and alerts to ensure accountability for flagging behavior.

Integration Tips: Log when thresholds or detection rules are changed, capture operator confirmations or overrides of flagged results, and periodically review logs for anomalies.

Verification Method: Audit logs for threshold changes and operator actions; confirm review cadence and access to logs.

Priority: Medium

6.2.10. R10: Generation of plain-language summaries and contextual explanations for findings

ISO 27001:2022 Controls

A.18.1.4

Requirement: Privacy and protection of personally identifiable information should be ensured as required in relevant legislation and regulation.

Relevance: Ensures that generated summaries containing PII or health information respect privacy constraints and legal protections when presented to users.

Integration Tips: Redact or limit PII in summaries where not necessary, ensure summaries are displayed only to authorized users, and record consent for providing health interpretations.

Verification Method: Check display permissions for summaries, inspect content for unnecessary PII, and verify consent records where required.

Priority: Medium

6.2.11. R11: Maintain and manage historical blood-test records with versioning and provenance

ISO 27001:2022 Controls

A.12.4.1

Requirement: Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed.

Relevance: Requires production and review of logs that support historical record management and periodic review of versioned records for anomalies.

Integration Tips: Ensure event logs capture version creation and modification events, secure log retention, and schedule periodic reviews focusing on historical record integrity.

Verification Method: Review logs for version events, inspect retention policies, and confirm periodic log reviews occurred.

Priority: Medium

6.2.12. R12: Time-series visualizations and charts with filters (test type, date range) and trend indicators

ISO 27001:2022 Controls

A.9.1.2

Requirement: Users should only be provided access to the network and services that they are authorized to use.

Relevance: Ensures only authorized users can access visualization services and datasets, preventing unauthorized viewing of time-series charts containing PII/PHI.

Integration Tips: Enforce role-based access checks on visualization APIs and UI; implement server-side authorization filtering based on user role and consent.

Verification Method: Test access controls across roles, attempt unauthorized access to filtered data, and review access control policies.

Priority: High

6.2.13. R13: Export capability for selected data to PDF and CSV with redaction and consent checks

ISO 27001:2022 Controls

A.18.1.4

Requirement: Privacy and protection of personally identifiable information should be ensured as required in relevant legislation and regulation.

Relevance: Supports ensuring PII in exported files complies with privacy legislation including consent and redaction obligations.

Integration Tips: Map export operations to legal requirements, ensure data minimization in exports, and record export consents and purposes.

Verification Method: Review export logs and consent records; validate that exports adhere to redaction policies and legal retention rules.

Priority: High

6.2.14. R14: Notification system: email and in-app notifications for analysis completion and alerts for out-of-range results

ISO 27001:2022 Controls

A.13.2.1

Requirement: Responsibilities and procedures for information transfer should be established to protect information in transit, including notifications.

Relevance: Requires policies and procedures for secure information transfer which apply to notification mechanisms to ensure confidentiality and integrity in transit (email/in-app).

Integration Tips: Define procedures for secure notifications, ensure TLS for email gateway integrations, and limit sensitive content in notifications (use in-app for detailed results).

Verification Method: Review procedures, test email gateway TLS and configuration, and confirm notification content minimization.

Priority: High

6.2.15. R15: Configurable notification preferences and escalation settings

ISO 27001:2022 Controls

A.9.1.1

Requirement: An access control policy should be established, based on business and security requirements.

Relevance: Provides policy-level backing for controlling who can configure notification and escalation settings, and enforces separation of duties where needed.

Integration Tips: Define who can change global escalation policies vs user-level preferences, enforce role-based restrictions and approval workflows for policy changes.

Verification Method: Review access control policy and test role restrictions on changing escalation settings.

Priority: Low

6.2.16. R16: Access control and role-based administration (user, clinician, admin, auditor)

ISO 27001:2022 Controls

A.9.1.1

Requirement: An access control policy should be established, based on business and security requirements.

Relevance: Provides a policy foundation for RBAC and administrative segregation of duties across system roles.

Integration Tips: Document RBAC policies, map roles to privileges, and ensure periodic access reviews and approvals are implemented.

Verification Method: Review access control policy and records of periodic access reviews and role mappings.

Priority: High

6.2.17. R17: Audit logging, monitoring, and tamper-evident trails for all sensitive operations

ISO 27001:2022 Controls

A.12.4.1

Requirement: Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed.

Relevance: Requires production, retention, and review of event logs covering sensitive operations to maintain monitoring and detection capabilities.

Integration Tips: Configure logging for sensitive operations, secure logs, automate review processes, and integrate with SIEM for alerting and analysis.

Verification Method: Inspect logging configuration, SIEM integration, and evidence of periodic reviews and alerts.

Priority: High

6.2.18. R18: Encryption of data in transit and at rest, key management, and secure storage

ISO 27001:2022 Controls

A.10.1.1

Requirement: A policy on the use of cryptographic controls should be developed and implemented to protect the confidentiality, authenticity and integrity of information.

Relevance: Provides organizational policy guidance for cryptography and key management that should govern implementations for data protection.

Integration Tips: Establish cryptography policy specifying acceptable algorithms, key lengths, and KMS usage; ensure developers follow policy and have guidance for implementation.

Verification Method: Review cryptography policy, enforce compliance via code reviews, and audit cryptographic usage.

Priority: High

6.2.19. R19: Third-party integration and vendor risk management for AI/OCR providers and email gateways

ISO 27001:2022 Controls

A.15.1.1

Requirement: Information security requirements for mitigating the risks associated with supplier’s access to the organization’s assets should be established and agreed with suppliers.

Relevance: Directly applies to vendor risk management for AI/OCR and email gateway providers by requiring agreed security requirements with suppliers.

Integration Tips: Include security clauses, DPA, and SLAs in contracts; require third-party assessments and periodic reviews, and limit data access on a least-privilege basis.

Verification Method: Review supplier contracts and DPAs, check assessment evidence, and confirm adherence to SLAs.

Priority: Critical

6.2.20. R20: Data retention, deletion (right to be forgotten), backup, and disaster recovery procedures

ISO 27001:2022 Controls

A.18.1.3

Requirement: Records should be protected to ensure they remain available and accurate over their required retention periods.

Relevance: Directs protection of records across retention periods, informing retention and deletion processes including the right to be forgotten for user data.

Integration Tips: Define retention schedules for clinical and PII data, implement deletion workflows aligned to legal obligations, and maintain verifiable deletion logs.

Verification Method: Review retention schedules, deletion logs and evidence of completed deletions, and legal mapping for retention periods.

Priority: Critical

6.3. Cross-Functional Security Controls

The following controls apply globally across all system components:

Audit Logging and Tamper Protection

Description: Capture and protect logs for authentication, consent, uploads, exports, AI outputs, and administrative actions; ensure logs are tamper-evident and access-controlled.

Applies to: R1, R3, R4, R6, R7, R8, R9, R11, R13, R14, R15, R17, R20

Implementation Guidance: Implement centralized logging (SIEM) with append-only storage or WORM, encrypt logs at rest, restrict log access, and retain logs per policy. Instrument application and infrastructure to emit detailed audit events and perform regular integrity checks.

Encryption and Key Management

Description: Ensure data in transit and at rest is encrypted using strong cryptography, and keys are managed securely with lifecycle policies.

Applies to: R4, R5, R13, R18, R20

Implementation Guidance: Use TLS for all network communications, encrypt storage with authenticated encryption, store keys in an enterprise KMS, enforce rotation and access controls, and validate cryptographic implementations against standards.

Access Control and Authorization Enforcement

Description: Centralized role-based access control and server-side enforcement to ensure users only perform authorized actions and access permitted data.

Applies to: R2, R11, R12, R13, R16, R18

Implementation Guidance: Implement RBAC/ABAC with centralized policy engine, enforce checks server-side in APIs, perform periodic access reviews, and log privilege changes for auditability.

Third-Party Risk Management

Description: Assess and manage risks from external providers (AI/OCR, email gateways) via contracts, assessments, and monitoring.

Applies to: R8, R14, R19

Implementation Guidance: Perform vendor security assessments, require DPAs and SLAs, limit data shared to minimum necessary, and monitor vendor performance and compliance periodically.

6.4. Requirements Traceability Overview

This section demonstrates complete traceability from high-level requirements through threats to security controls and verification methods.

Coverage Summary: Traceability matrix contains 20 requirements. 20 requirements (100.0%) linked to threats. 18 requirements (90.0%) mapped to security controls (OWASP ASVS, NIST SP 800-53, ISO 27001). Coverage: Complete.

Sample Traceability Mappings

The following table shows traceability for high-priority requirements:

Req ID	Requirement	Threats	Security Controls	Standards	Priority	Verification
REQ-001	User registration and login with multi-f…	10 threats	6 controls	ISO27001, NIST SP 800-53, OWASP ASVS	Critical	Review design documentation and authentication flows; test registration and login requiring MFA; attempt phishing/replay scenarios to confirm resistance; inspect configuration of MFA providers.
REQ-002	User profile management capturing person…	10 threats	4 controls	ISO27001, NIST SP 800-53, OWASP ASVS	Critical	Inspect sanitization procedures, verify secure deletion of test records on decommissioned media, and review backup retention/deletion logs.
REQ-003	User consent and privacy preferences man…	10 threats	4 controls	ISO27001, NIST SP 800-53, OWASP ASVS	Critical	Review architecture documentation and data flow diagrams; test enforcement of consent in downstream processes.
REQ-004	Secure upload pipeline supporting images…	10 threats	4 controls	ISO27001, NIST SP 800-53, OWASP ASVS	Critical	Inspect storage architecture, test for direct access to uploaded files, and confirm isolation/sandboxing of processing components.
REQ-005	Server-side file validation for allowed …	10 threats	4 controls	NIST SP 800-53, OWASP ASVS	Critical	Execute tests uploading malformed, oversized, or malicious files and verify they are rejected or quarantined; review scanner logs.
REQ-008	Perform OCR and AI-based structured data…	10 threats	4 controls	ISO27001, NIST AI RMF, NIST SP 800-53, OWASP ASVS	Critical	Review model governance artifacts and monitoring dashboards; test detection of drift and review remediation actions.
REQ-011	Persist historical blood-test records wi…	10 threats	4 controls	ISO27001, NIST SP 800-53, OWASP ASVS	Critical	Inspect protections on audit storage, attempt unauthorized modifications in test environment, and verify backups of audit information.
REQ-013	Allow export of selected data and report…	10 threats	3 controls	ISO27001, NIST SP 800-53, OWASP ASVS	Critical	Verify TLS and encryption used in export delivery, check file integrity mechanisms, and test access restrictions.
REQ-016	Role-based access control for users, cli…	6 threats	4 controls	ISO27001, NIST SP 800-53, OWASP ASVS	Critical	Review access control policy and records of periodic access reviews and role mappings.
REQ-018	Encrypt all sensitive data in transit (T…	10 threats	4 controls	ISO27001, NIST SP 800-53, OWASP ASVS	Critical	Review cryptographic libraries and configurations, run tool-based crypto checks, and perform code audits for improper use.

Showing 10 of 20 requirements. See Appendix D for complete traceability matrix.

Traceability Statistics

• Total Requirements Tracked: 20
• Requirements Linked to Threats: 20 (100.0%)
• Requirements Mapped to Controls: 18 (90.0%)
• Average Controls per Requirement: 3.4
• Control Distribution by Standard:
  • NIST SP 800-53: 27 controls
  • OWASP ASVS: 20 controls
  • ISO 27001: 18 controls
  • NIST AI RMF: 2 controls
• Verification Coverage: 100% (all requirements have verification methods)

---

7. AI/ML Security Requirements

This section addresses security requirements specific to artificial intelligence and machine learning components within the system. AI/ML systems introduce unique security challenges including prompt injection attacks, data poisoning, model theft, adversarial inputs, and bias vulnerabilities. This analysis identifies AI/ML components, assesses their security risks, and prescribes specialized controls to protect both the AI systems themselves and the data they process.

7.1. AI/ML Components Detected

This section identifies all AI/ML components within the system that require specialized security controls.

1. AI Data Extraction and Analysis: Utilizes Optical Character Recognition (OCR) and machine learning algorithms to extract structured data from uploaded blood test reports, identify abnormal values, and generate summaries.
   
2. Health History and Visualization: Employs machine learning techniques to visualize historical blood test data and identify trends over time.

7.2. AI/ML Threat Model

Component	Identified Threats
AI Data Extraction and Analysis	- Prompt injection
	- Data leakage (PII in training/prompts)
	- Model inversion attacks
	- Adversarial inputs
Health History and Visualization	- Data leakage (historical health data exposure)
	- Bias and fairness considerations
	- Model poisoning

7.3. AI/ML Security Controls

AI Data Extraction and Analysis

• Prompt Injection Prevention: Implement input sanitization to filter out potentially harmful inputs before processing.
  
• Input Validation for AI Inputs: Ensure that all inputs conform to expected formats and ranges before they are processed by AI components.
  
• Output Filtering and Sanitization: Use output validation mechanisms to scrub any sensitive information from the generated summaries.
  
• Data Leakage Prevention: Ensure that no personally identifiable information (PII) is included in the training datasets and utilize techniques like differential privacy.
  
• Model Access Controls: Restrict access to the model to authorized personnel only, implementing role-based access controls.
  
• Rate Limiting and Abuse Prevention: Introduce rate limiting to prevent abuse of the data extraction features, including throttling requests.
  
• Monitoring for Adversarial Inputs: Implement monitoring to detect unusual patterns of input that may indicate attempts at adversarial attacks.

Health History and Visualization

• Model Versioning and Rollback Capabilities: Maintain version control for ML models, allowing rollback to previous versions if vulnerabilities are discovered.
  
• Supply Chain Security for Models: Assess and verify third-party libraries and tools used in model training and deployment for vulnerabilities.
  
• Bias and Fairness Considerations: Regularly audit models for bias and ensure fairness in the analysis by utilizing fairness metrics and retraining as necessary.

7.4. Integration with Existing Security Controls

AI controls integrate with standard security practices by augmenting user authentication mechanisms (e.g., multi-factor authentication), data encryption protocols, and privacy policies. Additionally, audit logging and monitoring will ensure that all AI interactions are recorded and can be reviewed for compliance and security purposes. The established framework for data retention and deletion will work in conjunction with AI components to ensure sensitive information is managed appropriately.

7.5. AI/ML Monitoring Requirements

Monitoring Area	Description
Input Monitoring	Track and analyze inputs to detect anomalous patterns indicating potential adversarial attempts.
Output Monitoring	Review generated outputs for any instances of data leakage or inappropriate information disclosure.
Model Performance Monitoring	Regularly assess model performance and accuracy to identify drifts that may affect analysis quality.
Access Logs	Maintain detailed logs of all access to AI components, including modifications, requests, and errors.
Compliance Audits	Conduct regular audits to ensure adherence to security policies, especially regarding data handling.

---

8. Compliance Requirements

This section identifies regulatory and legal compliance obligations applicable to the system based on data types, geographic scope, industry sector, and business operations. Compliance requirements drive specific security controls, data handling procedures, audit capabilities, and privacy protections. Non-compliance can result in significant legal penalties, reputational damage, and business disruption. This analysis maps applicable regulations to specific security requirements and operational procedures.

8.1. Applicable Regulations

The identification of applicable regulations for the Blood Test Analysis Application was based on the types of data being handled, the geographic scope of users, the industry sector of healthcare, and specific business operations that involve the processing of sensitive health information. The application processes personal health data, which triggers several compliance requirements that directly impact security controls, data handling procedures, and operational processes essential for lawful operation. Below is a summary of the regulations identified:

Regulation	Applicability Reason
GDPR	Applies because the system processes personal data of EU residents.
CCPA	Applies since the application collects personal data of California residents.
HIPAA	Applies due to the handling of protected health information (PHI).
HITECH	Applies as it enhances the privacy and security protections established under HIPAA.
PCI-DSS	Potentially applicable if payment information is processed in future iterations of the application.
COPPA	Applies if the application collects personal data from children under 13 years of age.
Data Residency Laws	Applies based on the geographic locations of users and their associated data protection laws.

8.2. Compliance Controls by Regulation

GDPR

• Implement user consent mechanisms for data processing.
• Ensure data minimization and purpose limitation in data handling.
• Provide users with access to their data and the ability to delete it (Right to be Forgotten).
• Implement data encryption for data in transit and at rest.
• Maintain audit logs of user consent and data access.

CCPA

• Enable users to opt-out of the sale of their personal data.
• Provide a clear privacy notice detailing data collection practices.
• Allow users to access their data and request deletion.
• Implement a secure method for users to submit data requests.

HIPAA

• Ensure strict access controls for PHI.
• Conduct regular risk assessments to identify vulnerabilities.
• Provide training to staff on data privacy and security protocols.
• Implement secure transmission methods for sharing PHI.

HITECH

• Establish breach notification procedures in case of unauthorized access to PHI.
• Implement updated security measures for electronic health records.
• Ensure third-party service providers comply with HIPAA standards.

PCI-DSS

• If applicable, implement secure payment processing controls.
• Encrypt cardholder data during transmission and storage.
• Maintain a secure network with firewalls and access controls.

COPPA

• Obtain verifiable parental consent before collecting personal data from children under 13.
• Implement age verification processes.

Data Residency Laws

• Ensure data is stored in compliance with local regulations regarding data residency.
• Implement geo-blocking controls if required by local laws.

8.3. Data Subject Rights

Right	Description
Right to Access	Users have the right to access their personal data.
Right to Rectification	Users can request corrections to their personal data.
Right to Deletion	Users can request deletion of their personal data.
Right to Data Portability	Users can request their data in a structured format.
Right to Withdraw Consent	Users can withdraw consent at any time.

8.4. Privacy Requirements

Consent: Users must provide explicit consent for data processing activities.
Privacy Notice: A clear and comprehensive privacy notice must be provided to users detailing data collection and processing practices.
User Preferences: Users must have the ability to manage their privacy preferences easily.

8.5. Audit and Monitoring Requirements

Logging: Maintain detailed audit logs of all access and modifications to personal data.
Monitoring: Implement continuous monitoring of data access and user activity to detect potential breaches.

8.6. Data Handling Rules

Retention: Data must be retained only as long as necessary for its intended purpose and in accordance with legal requirements.
Deletion: Implement procedures for the secure deletion of personal data upon user request or when no longer needed.
Backup: Regular backups of data must be maintained to prevent loss and ensure recoverability.

8.7. Compliance Risk Assessment

The Blood Test Analysis Application presents several compliance risks due to the sensitive nature of health data being processed and the regulatory requirements associated with it. A thorough compliance risk assessment should be conducted to identify potential vulnerabilities and implement appropriate mitigation strategies.

Key Compliance Risks:

• Unauthorized access to sensitive health information, which could lead to breaches of HIPAA and GDPR.
• Non-compliance with user consent requirements under GDPR and CCPA, exposing the organization to penalties.
• Potential mishandling of personal data that could result in legal actions or reputational damage.

---

9. Security Architecture Recommendations

This section provides comprehensive security architecture guidance that integrates security controls into the system’s technical design. Security architecture defines how security principles, controls, and patterns are applied across system components to create a cohesive, defense-in-depth security posture. The recommendations address architectural principles, component-level controls, data protection strategies, and third-party integration security to ensure security is built into the system design.

9.1. Architectural Security Principles

Architectural security principles provide the foundational philosophy guiding all security design decisions. These principles ensure a consistent security posture across all system components and guide the selection and implementation of security controls. They are used to make trade-offs explicit, enforce consistent risk treatment, and ensure regulatory and privacy obligations are met across the blood test analysis application.

• Zero Trust Architecture principles
  Never trust, always verify: all access requests are authenticated and authorized regardless of network location. This reduces implicit trust in network zones and ensures continuous verification for access to PHI/PII.

• Defense in Depth
  Multiple, overlapping layers of controls (network, host, app, data, identity) provide redundancy so that no single control failure leads to a total compromise.

• Principle of Least Privilege
  Users, services, and processes are given only the minimum rights required. This reduces blast radius for both accidental and malicious actions.

• Secure by Default / Secure by Design
  Default configurations should be secure (secure cryptography, no debug endpoints, strict permissions). Security is an integral design consideration for every feature, not an afterthought.

• Separation of Duties
  Sensitive responsibilities (administration, audit, consent management, QA) are split across individuals and systems to prevent single-person abuse and enable checks & balances.

• Fail Secure (Safe Failure)
  When failures occur, systems must default to secure states (deny access, pause processing of sensitive data, return safe errors) to avoid leaking data or enabling unsafe behavior.

• Complete Mediation
  Every access request to a resource (files, APIs, data views) is checked against current authorization policy — do not rely on cached or client-side checks alone.

• Defense in Depth for AI/ML
  Treat models and inference as assets requiring model access controls, input validation, provenance logging, confidence scoring and explainability for safety-critical outputs.

• Privacy by Design & Data Minimization
  Collect the minimum necessary data, capture and enforce consent and purpose limitations, and embed privacy controls (redaction, pseudonymization) before sharing data externally or to models.

• Immutable Auditability & Tamper Evidence
  Maintain append-only, tamper-evident logs for consent, uploads, model outputs, exports and admin actions to satisfy compliance and forensic needs.

• Secure Supply-Chain & Vendor Management
  Validate third-party services (AI/OCR, email gateways, identity providers) for security posture and limit data shared; require contractual DPAs and monitoring.

---

9.2. Component-Level Security Controls

Frontend Layer

Required Controls:

• Enforce TLS 1.2+ (TLS 1.3 preferred) for all browser and mobile communications.
• Use OIDC/OAuth2 Authorization Code flow with PKCE for authentication.
• Protect tokens: short-lived access tokens, refresh tokens stored securely (secure cookie with HttpOnly+Secure+SameSite or platform secure storage like Keychain/Keystore).
• Client-side input validation for UX only; enforce server-side validation for all inputs.
• Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, and other secure headers.
• Protect against XSS and CSRF (CSRF tokens/ SameSite cookies) on interactions that change state.
• Strict CORS whitelist for allowed origins.
• Secure local storage practices (no PHI persisted insecurely on device).
• Mobile camera upload permission/consent UX and explicit user consent capture for PHI sharing.

Recommended Patterns:

• SPA + OIDC/OAuth2 (Authorization Code + PKCE) for authentication.
• Use secure cookie session or token exchange via a backend for sensitive operations.
• CDN for static assets with strict origin protections and signed URLs for private assets.
• Use platform-native secure storage on mobile (Keychain / Android Keystore) and ephemeral caches.
• Sentry/Feature flag systems integrated with PII scrubbing.

Edge Layer

Required Controls:

• Terminate TLS with strong ciphers, enforce TLS 1.2+ and prefer 1.3; maintain HSTS.
• Web Application Firewall (WAF) with OWASP rulesets and custom rules for expected report upload flows.
• API Gateway enforcing authentication, rate limiting, IP-based controls and request validation.
• DDoS protection and bot mitigation configured (rate-limits, challenge pages).
• Validate and verify JWT tokens (issuer, audience, signature, expiry) at edge.
• Reject or throttle anomalous payloads (file sizes, request rate, unexpected content types).

Recommended Patterns:

• CDN + WAF + API Gateway integration for fronting all public endpoints.
• API Gateway performing JWT/OAuth token validation and routing to internal services.
• mTLS or private network links between API Gateway and internal backend services where supported.
• Edge input validation and schema checking (reject malicious or malformed requests early).

Application Services

Required Controls:

• Server-side RBAC/ABAC enforcement for all APIs; centralized policy decision point (PDP).
• Input validation and sanitization for uploads and metadata (MIME-type check, signature/magic bytes).
• Malware scanning and content disarm & reconstruction (CDR) or sandboxing for uploaded files before processing.
• Queued asynchronous processing for OCR/AI with isolated worker pools and ephemeral compute for inference jobs.
• Per-job provenance logging including job IDs, timestamps, user ID, file checksum, initial metadata and decision artifacts.
• Store only minimized data for external calls; redact PHI before sending to third parties where possible.
• Attach confidence scores, source references and explainability metadata to AI outputs.
• Rate limiting, request throttling and circuit breakers for third-party calls.
• Secure secrets management (rotate credentials, no secrets in code) and least-privileged service accounts.
• Strong telemetry and metrics emission (no raw PHI in telemetry).

Recommended Patterns:

• Microservices with clear bounded contexts (ingest, processing, AI, notifications, audit).
• Worker queue pattern for async OCR/AI (message queue with durable, authenticated access).
• Sidecar security (service mesh) to enforce mTLS, policy and telemetry between services.
• Use containers with runtime policy enforcement (seccomp, AppArmor, read-only filesystems) and ephemeral processing nodes for untrusted files.
• Pre-signed object storage URLs for direct upload from clients; server validates before kick-off of processing job.

Data Storage

Required Controls:

• Encrypt data at rest with strong authenticated encryption; separate keys per environment and data class.
• Column-level or field-level encryption for PHI (e.g., patient identifiers, lab results) in DB.
• Object storage configured with server-side encryption (SSE-KMS) and access restricted via IAM roles and signed URLs.
• Database access restricted within VPC/subnet, only from authorized service accounts.
• Backups encrypted, immutable (WORM or object lock where supported) and access-controlled.
• Auditable retention/deletion workflows with verifiable logs for right-to-be-forgotten requests.
• Data integrity controls: checksums/hashes for files & records and provenance metadata stored in audit log.

Recommended Patterns:

• Managed RDBMS with TDE (Transparent Data Encryption) + column-level encryption for PHI.
• Encrypted object storage (SSE-KMS) + object versioning and lifecycle policies.
• Use KMS with HSM-backed master keys for envelope encryption.
• Database row-level security (RLS) for multi-tenant or role-based data isolation.
• Isolated storage accounts/projects for production, staging and test (no production PHI in non-prod).

Identity & Security Services

Required Controls:

• Centralized identity provider (enterprise IdP) supporting OIDC, SAML, SCIM and MFA (FIDO2, TOTP or push-based authenticators).
• Enforce MFA for privileged accounts and high-impact operations (registration recovery, exports).
• Role-based provisioning/deprovisioning (SCIM) with automated offboarding.
• Key Management Service (KMS) for keys and certificates with strict access policies and rotation.
• Centralized audit logging, SIEM ingestion and monitoring for identity events and policy changes.
• Consent capture and immutable consent records (timestamped, purpose, scope).
• Policy engine for ABAC/RBAC decisions and separation-of-duties enforcement.

Recommended Patterns:

• Enterprise IdP + OIDC integration for application auth and federation.
• Use SCIM and SSO for provisioning clinician and admin accounts.
• HSM-backed KMS for master key protection and envelope encryption.
• Centralized authorization engine (OPA, AWS IAM, Cloud Authorization) as a service for consistent policy enforcement.

External Services

Required Controls:

• Contractual DPAs, SLAs, security questionnaires and SOC 2/ISO27001 evidence for each vendor.
• Minimize data shared with vendors (send only required fields, redact PHI where possible).
• Secure API authentication (OAuth2 client credentials, mTLS, API keys rotated) and strict egress controls.
• Monitor usage, logs, and anomalous vendor behavior; alert on data exfiltration patterns.
• Formal vendor onboarding and continuous assessment.

Recommended Patterns:

• Isolate vendor integrations in separate network segments or dedicated projects/accounts.
• Use gateway proxies or token translation layers to mediate and reduce sensitive data shared directly with vendors.
• Implement strict API rate-limiting and circuit breakers for vendor endpoints.

---

9.3. Data Protection Strategy

Data Classification: Public, Internal, Confidential, Restricted

• Public — Non-sensitive UI text, generic help content.
• Internal — Operational telemetry, non-PII logs, system metrics.
• Confidential — User PII (name, email), account metadata and upload metadata that are not health-specific.
• Restricted — PHI/health data (raw reports, parsed lab results, analysis summaries), consent records, and audit logs.

Encryption Requirements:

• Data in transit: TLS 1.2 minimum; TLS 1.3 preferred. Use strong cipher suites (AEAD suites, ECDHE for key exchange). Enforce HSTS, OCSP stapling and certificate pinning where appropriate (mobile apps).
• Data at rest (object storage): AES-256-GCM for authenticated encryption. Use envelope encryption with KMS-managed DEKs and HSM-backed CMKs for master keys.
• Database: TDE for disk-level encryption; column/field-level encryption (AES-256-GCM) for PHI and PII. Use database-native encryption + application-level encryption for highest-sensitivity fields (PHI identifiers).
• Key algorithms and lengths: AES-256 for symmetric keys; RSA 3072+ or ECDSA secp384r1 for asymmetric where required. Use modern key derivation (HKDF).
• Key lifecycle: KMS-managed keys rotated on a policy (e.g., CMK rotation annually or per-organizational policy). Enforce key usage audit logs and split roles for key management.
• Secrets: Store secrets in a managed secrets manager (not in source code or container images). Restrict secret access to minimal service accounts.

Retention Policies:

• Default user PHI retention: retain user clinical data for the user account lifetime plus legal retention requirement (e.g., configurable 7 years by default, subject to jurisdictional law). Map retention by jurisdiction (GDPR, HIPAA, local health data laws).
• Consent records: retain for as long as data processing occurs + statutory obligations (e.g., min 7 years).
• Audit logs: retain high-fidelity logs (immutable) for regulatory timeframe (e.g., 7–10 years) depending on compliance; retain critical forensic logs longer as required.
• Backups: Retention per policy with immutable snapshots; maintain retention schedule and deletion windows separate from primary deletion to ensure right-to-be-forgotten propagation.
• Right-to-be-forgotten: Implement staged deletion where production copies and indexed search entries are deleted immediately; backups are scheduled for purging per policy and legal holds can suspend deletion where required.

Handling Procedures:

• Access:
  • Enforce RBAC/ABAC for all data access; server-side checks for all read/write operations.
  • Require MFA for privileged operations (exports, deletion, admin UI).
  • Use just-in-time (JIT) elevation for admin tasks where possible.
• Transmission:
  • Always use TLS for network transit; enforce mTLS for backend-to-backend vendor and intra-service comms where possible.
  • For external transfers (email attachments, third-party APIs), minimize content in the payload and prefer in-app notifications with authenticated links to the protected resource.
• Storage:
  • Store PHI in encrypted databases / object stores with field-level protections and limited service account access.
  • Use immutable audit logs and maintain provenance metadata (file checksum, upload metadata, user ID).
• Deletion:
  • Implement verifiable deletion workflows: delete primary records, remove copies from caches/indices, mark backup snapshots for deletion and log deletion events. Provide users evidence of deletion (audit event).
  • For backups and immutable storage, implement retention-controlled deletion and document timelines for irrecoverable deletion.
• Export & Redaction:
  • Apply redaction rules on exports (PDF/CSV) based on consent and recipient role; sign exports and encrypt at rest/in transit (e.g., TLS + optional password-protected PDF).
  • Log each export event with user ID, data included, and justification.
• De-identification for model training:
  • Remove PII/PHI unless explicit consent for training is captured. Apply robust de-identification (tokenization, hashing with salt, k-anonymity where applicable) and document datasets used for model evaluation.
• Incident Handling:
  • Immediately isolate impacted dataflows, revoke or rotate keys when required, log and notify affected users per law (Breach notification requirements) and escalate to incident response team.

---

9.4. Third-Party Integration Security

AI/OCR Provider (e.g., OCR/ML SaaS)
Security Requirements:

• Use least-privilege API credentials (OAuth2 client credentials or scoped API keys).
• Use encrypted channels (HTTPS/TLS 1.2+) and prefer mTLS for vendor API calls.
• Vendor must agree to a DPA and permit audits / provide SOC2/ISO27001 evidence.
• Minimize data shared: send redacted text or tightly-scoped images where possible.
• Require vendor to provide confidence scores, explainability metadata and model provenance info.

Risk Assessment: High — processes restricted PHI/PHI derivatives; inaccurate extraction can cause clinical risk; vendor compromise may leak sensitive health data.

Recommended Controls:

• Employ an API gateway/proxy to mediate and scrub PHI before sending to vendor.
• Rate limit and circuit-breaker vendor calls to avoid exfiltration via high-frequency calls.
• Log vendor requests & responses (scrubbed of raw PHI) and perform anomaly detection on vendor usage.
• Periodic vendor assessments and revalidation of model accuracy on representative datasets.

---

Email/SMS Gateway Providers
Security Requirements:

• Use TLS for SMTP/API integrations and prefer authenticated API endpoints (OAuth2/mTLS).
• Tokens / API keys stored in KMS/secrets manager and rotated regularly.
• Minimal content in outbound messages (avoid PHI in email or SMS bodies; use in-app messages with secure links instead).
• DPAs and contractual obligations for message content retention.

Risk Assessment: High — risk of inadvertent PHI disclosure through notification content; SMS is insecure and should not carry PHI.

Recommended Controls:

• Restrict notifications to non-sensitive content over email/SMS (e.g., “Analysis complete — see app”).
• Use in-app notifications for sensitive alerts; if email includes sensitive content, encrypt attachments and require authenticated download.
• Monitor delivery logs and alert on abnormal volumes or failed deliveries.
• Implement suppressions and user preferences enforcement to avoid sending to users who revoked consent.

---

External Identity Provider (Federated IdP / SSO)
Security Requirements:

• Use OIDC or SAML with signed assertions and enforce strong session controls.
• Enforce SSO MFA/external policy for privileged users; SCIM for provisioning/deprovisioning.
• IP restrictions, trust stores and merchant-of-record for trusts.

Risk Assessment: High — IdP compromise can enable broad access; federation configuration errors can lead to account takeover.

Recommended Controls:

• Enforce strict relying-party configuration: allowed audiences, valid issuer, certificate rotation monitoring.
• Implement periodic verification of SCIM sync; automated offboarding upon HR events.
• Fallback local admin accounts with emergency break-glass workflow audited and limited.

---

CDN/WAF Provider
Security Requirements:

• Support TLS 1.2+ and certificate management APIs.
• Provide WAF rule tuning, logging, and exportable logs to SIEM.
• DDoS protection SLA and controls for rate-limiting.

Risk Assessment: Medium — misconfiguration can allow web attacks or leakage of signed URLs.

Recommended Controls:

• Configure origin authentication and signed URLs for private assets.
• Export WAF logs to SIEM; tune rules to reduce false positives.
• Use origin access control (private origin endpoints) so CDN is the only public ingress to storage.

---

Cloud Object Storage Provider
Security Requirements:

• Support server-side encryption with customer-managed keys (SSE-KMS) and optional client-side encryption.
• Ability to support object versioning, lifecycle policies, object locking (WORM).
• VPC/private endpoint support with IAM controls.

Risk Assessment: High — storage compromise exposes raw reports and PHI.

Recommended Controls:

• Use SSE-KMS with HSM-backed CMKs and IAM roles for access.
• Use pre-signed, short-lived URLs for uploads; validate object integrity via checksums.
• Enable object lock/worm for audit logs and immutable snapshots.

---

Managed Relational Database Provider
Security Requirements:

• TDE or equivalent, network isolation (VPC), database auditing and role separation.
• Fine-grained DB access controls and encryption of backups.

Risk Assessment: High — central store of parsed lab data and PII.

Recommended Controls:

• Enforce DB network access only from application subnets, use IAM-based DB authentication where applicable.
• Enable auditing and forward logs to SIEM; separate analytic read-only replicas from write DB to limit exposure.

---

Message Queue / Task Queue Service
Security Requirements:

• Enforce authenticated connections (IAM, mTLS) and scoped credentials.
• Message encryption at rest and in transit, ack semantics.
• Replay protection and message integrity checks (signatures/checksums).

Risk Assessment: Medium — malicious injection or queue access can manipulate processing flow.

Recommended Controls:

• Use per-service credentials with least privilege for queue operations.
• Monitor queue depth and consumer behavior for anomalies; use dead-letter queues for suspicious content.
• Encrypt message payloads containing PHI and limit message retention.

---

SIEM / Logging / Monitoring Provider
Security Requirements:

• Encrypted log ingestion, role-based access and log integrity (append-only or WORM).
• Capability to mask/scrub PHI in logs before ingestion.

Risk Assessment: Medium — logs may contain sensitive context and must be protected.

Recommended Controls:

• Implement log scrubbing at log agent stage to remove or redact PHI.
• Store logs in append-only / immutable channels and control access with strong RBAC.
• Integrate alerts & runbooks for security events.

---

9.5. How it all Works Together (Holistic View)

• Authentication & Access: Users authenticate via OIDC to IdP (MFA enforced). Frontend exchanges tokens via PKCE and uses short-lived tokens. API Gateway validates tokens (JWT claims), enforces rate limits and routes to internal services.
• Upload Flow: Client uses pre-signed, short-lived upload URLs to object storage to reduce data egress through backend. Upload metadata and checksums are recorded to the audit trail. Edge layer enforces size/type limits and triggers a server-side validation job.
• Ingest & Processing: Ingest service validates MIME signatures, scans for malware, then enqueues a processing job (worker pool in isolated runtime). Worker runs OCR/AI in sandboxed environment; all calls to third-party OCR are mediated by proxy and only minimally redacted content is shared. Each job emits provenance events and stores outputs in encrypted storage with associated confidence scores and explainability metadata.
• Data Access & Visualization: Visualization APIs enforce server-side RLS and ABAC policies checking consent and role before returning time-series results. Exports require explicit consent and use export pipeline that applies redaction rules and encrypts output.
• Notifications: In-app notifications contain full context; email/SMS only notify completion or send secure links. Notification sends are logged and respect user preferences.
• Audit & Monitoring: All sensitive operations (uploads, consent changes, exports, admin actions, model outputs) are logged to an immutable SIEM store; alerts are generated for anomalies, data exfiltration patterns or model drift.
• Key Management & Secrets: All cryptographic keys and secrets are centrally stored in HSM-backed KMS/secrets manager with role separation for key admins and application users.
• Vendor Controls: Vendor integrations run through an API proxy that applies data minimization, retries, and circuit-breakers; vendors are reassessed periodically and contractual DPAs are enforced.

---

9.6. Operational & Governance Recommendations

• Secure SDLC: Static & dynamic analysis, dependency scanning, secret scanning in CI/CD. Require security reviews for model updates and data schema changes.
• Penetration Testing & Red Teaming: Annual third-party pentests and continuous bug bounty where appropriate; tabletop exercises for breach scenarios and regulatory reporting.
• Model Governance: Maintain model registry, validation tests, bias testing, drift monitoring, and rollback capabilities. Log model inputs/outputs (with privacy safeguards) for reproducibility.
• Incident Response & Breach Notification: Predefined runbooks for PHI exposure, legal notification templates by jurisdiction, containment steps (rotate keys, revoke tokens), and post-incident reviews.
• Data Privacy & Legal: DPIA for processing PHI and use of AI. Consent capture UX must be explicit and linked to stored consent records. Implement legal hold capability to suspend deletion.
• Change & Configuration Management: Infrastructure as Code (IaC) with policy-as-code guards (e.g., OPA, Terraform sentinel). Immutable infrastructure and minimal manual changes to prod.
• Continuous Monitoring & SLOs: Uptime and processing SLOs for ingest/analysis pipelines; alerting thresholds for anomalous usage, pipeline failures and vendor latency.

---

9.7. Checklist for Deployment & Compliance Verification

• Enforce MFA (FIDO2/TOTP) and secure password recovery flows with out-of-band verification.
• All public endpoints pass TLS 1.3 or 1.2 with strong ciphers and HSTS.
• Upload pipeline validates file signatures, runs malware scanning and sandboxing prior to processing.
• PHI encrypted at rest (AES-256-GCM) with KMS-backed keys and envelope encryption.
• RBAC/ABAC policies enforced server-side with periodic certification.
• Immutable audit logs in WORM storage with SIEM alerts configured for suspicious activity.
• Vendor DPAs, SOC2/ISO27001 evidence collected and reviewed; minimal data shared with vendors and periodic reassessments scheduled.
• Exports and notifications respect user consent and are logged.
• Retention & deletion flows implemented and tested for right-to-be-forgotten; backup deletion documented.

---

Adopting the above principles, component controls, data protection strategy, and third-party controls will produce a defense-in-depth, privacy-forward architecture tailored to protect sensitive medical data for the Blood Test Analysis Application while enabling scalable AI-based processing and rich user experiences.

---

10. Implementation Roadmap

This section provides a prioritized, phased approach for implementing the security controls identified throughout this analysis. The roadmap organizes security measures into logical phases based on risk, dependencies, and resource availability, ensuring critical security gaps are addressed first while building a foundation for comprehensive security coverage.

10.1. Prioritization Framework

Prioritization is critical for effective security implementation as it ensures that the most significant risks and compliance requirements are addressed first, optimizing resource allocation and reducing the likelihood of breaches. Here’s how we prioritize:

Prioritization Criteria:

• Risk Level: Controls addressing critical and high-risk threats (identified through threat modeling) are prioritized first

• Compliance Deadlines: Regulatory requirements and compliance deadlines influence immediate priority

• Technical Complexity: Controls requiring foundational infrastructure are implemented early to enable subsequent controls

• Dependencies: Controls that other security measures depend upon are prioritized accordingly

• Resource Availability: Implementation considers the availability of skilled personnel, tools, and budget

• Business Impact: Controls protecting business-critical functions and data receive higher priority

These criteria work together to create a logical implementation sequence that balances security needs with practical constraints, ensuring that the most pressing security gaps are filled quickly while laying the groundwork for future controls.

10.2. Phased Implementation Plan

Phase: IMMEDIATE

Timeline: 0-1 months

Rationale: Address critical vulnerabilities and compliance blockers to protect sensitive data and meet legal requirements promptly.

Controls to Implement:

• Enforce multi-factor authentication for all user and admin accounts
• Implement basic encryption for sensitive data in transit and at rest
• Configure TLS 1.2+ across all network communications
• Perform immediate patching on critical vulnerabilities identified in threat assessments

Dependencies:

• None

Phase: SHORT-TERM

Timeline: 1-3 months

Rationale: These controls build upon immediate security measures, focusing on improving access control adjustments and ensuring that logging and API security mitigate identified threats effectively.

Controls to Implement:

• Enhance user authentication through comprehensive multi-factor authentication
• Deploy role-based access controls across the admin dashboard
• Implement comprehensive logging and monitoring for all administrative actions
• Strengthen API security with input validation and HTTPS protocols
• Begin encryption for all sensitive data at rest

Dependencies:

• Completion of TLS Implementation
• Completion of multi-factor authentication

Phase: MEDIUM-TERM

Timeline: 3-6 months

Rationale: Implement important controls requiring more planning to bolster overall system security and prepare for potential advanced threats.

Controls to Implement:

• Deploy advanced threat detection and response systems
• Automate security testing and vulnerability scanning
• Conduct third-party security audits for vendor risk management
• Enhance data protection measures, including data masking and anonymization

Dependencies:

• Completion of comprehensive logging and monitoring
• Completion of API security enhancements

Phase: LONG-TERM

Timeline: 6-12 months

Rationale: Implement strategic initiatives for long-term security maturity and resilience.

Controls to Implement:

• Develop security maturity enhancements across the organization
• Implement advanced AI/ML security controls for threat detection
• Conduct comprehensive penetration testing to identify any residual vulnerabilities
• Launch a security awareness program to educate all employees

Dependencies:

• Completion of advanced threat detection deployment
• Completion of security testing automation

Phase: ONGOING

Timeline: Continuous

Rationale: Maintain a state of readiness and adapt to evolving threats through continuous monitoring and audits.

Controls to Implement:

• Conduct security monitoring with real-time alerts
• Manage patch management and apply updates regularly
• Perform compliance audits to ensure ongoing regulatory adherence
• Maintain incident response readiness with regular drills and updates

Dependencies:

• Ongoing integration with SIEM tools and monitoring solutions

10.3. Resource Requirements

“Skills: Security engineers, Security architects, Web developers, Compliance specialists; Recommended tools: SIEM solutions for logging and monitoring, Vulnerability scanners for testing, Encryption libraries for data protection, API management tools for secure interfaces; Estimated time effort: Approximately 3-6 months for initial phases, with ongoing efforts extending resources as per system complexity and requirements.”

---

11. Verification and Testing Strategy

11.1. Testing Approach

Integrate security testing throughout the software development lifecycle (SDLC) with an emphasis on continuous security practices. Balance automated scanning with manual evaluations to prioritize high-risk areas based on business impact, adhering to shift-left security principles by incorporating security testing earlier and continuously. This approach will ensure that security is embedded into every phase of development, enabling faster identification and remediation of vulnerabilities while complying with relevant regulatory frameworks.

11.2. Testing Methods

Method	Frequency	Tools
STATIC APPLICATION SECURITY TESTING (SAST)	Every commit/build	SonarQube, Semgrep, Checkmarx, CodeQL
DYNAMIC APPLICATION SECURITY TESTING (DAST)	Nightly/weekly	OWASP ZAP, Burp Suite, Acunetix
DEPENDENCY SCANNING	Every build	Snyk, Dependabot, OWASP Dependency-Check
SECRETS SCANNING	Every commit	TruffleHog, GitLeaks, GitHub Secret Scanning
CONTAINER/INFRASTRUCTURE SCANNING	Every deployment	Trivy, Clair, Prowler, ScoutSuite
PENETRATION TESTING	Quarterly or before major releases	Custom scripts, Metasploit, Burp Suite Pro
SECURITY CODE REVIEW	For critical features	GitHub/GitLab code review, security checklists
COMPLIANCE SCANNING	Continuous	AWS Config, Azure Policy, Cloud Custodian

11.3. Compliance Verification

Multi-standard compliance (OWASP ASVS, NIST SP 800-53, ISO 27001) will be verified through automated tools and manual checks against regulatory requirements such as GDPR, CCPA, HIPAA, and PCI-DSS. Audit preparation will involve ensuring documentation and evidence collection for external audits, including maintaining detailed logs and consent records. Recommendations will include engaging third-party auditors to conduct comprehensive evaluations of compliance posture and address any identified gaps.

11.4. Continuous Monitoring

Implement Security Information and Event Management (SIEM) for real-time monitoring, supported by Intrusion Detection/Prevention Systems (IDS/IPS) to identify and mitigate threats. All logs will be aggregated and analyzed for anomalies, with integration into incident response processes to ensure prompt action against security events. Continuous monitoring will also include regular assessments of vendor compliance and performance to manage third-party risks effectively.

11.5. Key Performance Indicators (KPIs)

• Mean time to detect (MTTD) security issues
  
• Mean time to remediate (MTTR) vulnerabilities
  
• Percentage of critical vulnerabilities patched within SLA
  
• Security test coverage percentage
  
• False positive rate in automated scanning
  
• Compliance audit pass rate

11.6. Mapping Testing Methods to Security Controls

Testing Method	Security Controls Verified
STATIC APPLICATION SECURITY TESTING (SAST)	Input validation, injection flaws, hardcoded secrets
DYNAMIC APPLICATION SECURITY TESTING (DAST)	Authentication, authorization, XSS, CSRF, SQL injection
DEPENDENCY SCANNING	Supply chain security
SECRETS SCANNING	Cryptographic protection
CONTAINER/INFRASTRUCTURE SCANNING	Configuration management
PENETRATION TESTING	All high-risk controls
SECURITY CODE REVIEW	Authentication, authorization, crypto implementations
COMPLIANCE SCANNING	All compliance-related controls

---

12. Validation Report

This section presents a comprehensive validation of the security requirements generated throughout this analysis. The validation evaluates the requirements against five key dimensions: completeness, consistency, correctness, implementability, and alignment with business objectives. This assessment ensures that the security requirements are comprehensive, technically sound, and actionable for implementation teams.

12.1. Overall Assessment

The overall validation score reflects the quality and completeness of the security requirements across five critical dimensions. Each dimension is scored from 0.0 to 1.0, with 1.0 representing excellent coverage and 0.0 indicating significant gaps.

Overall Score: 0.85/1.0

Validation Status: ✅ PASSED

The security requirements have met the quality threshold (≥0.8) and are ready for implementation. The requirements demonstrate comprehensive coverage, technical accuracy, and alignment with business objectives.

The validation assesses:

• Completeness: Are all identified security concerns adequately addressed?
• Consistency: Do requirements align with each other without contradictions?
• Correctness: Are controls appropriate for the identified risks and correctly applied?
• Implementability: Are requirements specific, actionable, and feasible to implement?
• Alignment: Do security requirements align with business requirements and objectives?

12.2. Dimension Scores

Dimension	Score	Status
Completeness	0.78	⚠️
Consistency	0.90	✅
Correctness	0.90	✅
Implementability	0.80	✅
Alignment	0.88	✅

Score Interpretation: - ✅ 0.8-1.0: Excellent - ⚠️ 0.7-0.79: Acceptable (minor improvements needed) - ❌ <0.7: Needs significant improvement

12.3. Detailed Feedback

Summary of assessment: The security requirements provide strong, relevant coverage across authentication, authorization, data protection, AI/ML governance, vendor management, logging, and privacy — and they align well with the blood-test application business needs. Strengths include mapping to OWASP ASVS and NIST/ISO controls, AI-specific threat modelling and mitigations, vendor risk controls, and explicit requirements for encryption, audit logging, and consent management.

Identified gaps and prioritized, actionable recommendations (practical, developer-friendly): 1) Incident Response & Vulnerability Management (High priority) - Add explicit IR requirements: incident detection to notification timelines (e.g., SLA: 72 hrs for breach notification), designated response roles, forensic evidence collection standards, and tabletop test cadence. - Add vulnerability management: SAST/DAST schedules, dependency SCA, CVE triage process, patch timelines based on severity, and penetration testing frequency (annual + release-driven).

2. Secure SDLC & Testing (High priority)
   • Require secure development lifecycle controls: developer security training, code review policies, pre-production security gates, CI/CD scanning, secrets scanning, and pipeline hardening.
   • Define acceptance criteria for security controls (e.g., OWASP Top 10 automated tests must pass before merge).
3. API / Session / Web Security Details (High priority)
   • Specify API auth schemes (OAuth2 + PKCE for SPAs, short-lived access tokens, refresh token handling, token revocation endpoints).
   • Add session management specifics: session timeout, idle timeout, secure cookie flags, logout/invalidation semantics.
   • Include explicit protections for CSRF, XSS, clickjacking, and input validation for non-AI inputs (server-side enforcement).
4. Data Deletion, Backups, and Forensics (High priority)
   • Define verifiable deletion requirements: how to remove data from primary storage and backups (logical and physical/cryptographic erasure), retention periods, and proof-of-deletion records for user Right-to-Be-Forgotten requests.
   • Include backup encryption and retention lifecycle with testing of deletion and recovery.
5. AI/ML Controls — make them prescriptive and testable (Medium-High)
   • Specify concrete anti-prompt-injection controls: structured pre-processing pipeline, whitelist/blacklist rules, parser-based extraction fallback.
   • Define metrics and thresholds for model accuracy, false-positive/negative targets, minimum confidence for auto-flagging, and mandatory human-in-the-loop for high-risk flags.
   • Add privacy-preserving training requirements (differential privacy parameters or synthetic-data usage) and rules for logging model inputs/outputs (redaction & retention).
   • Require continuous model monitoring KPIs and automated drift detection with alerting and rollback procedures.
6. Logging, Retention & Privacy (Medium)
   • Specify log retention durations by log type and legal regime, log anonymization/pseudonymization rules for analytics, and exact tamper-evidence techniques (e.g., WORM-backed SIEM, signed log delivery).
   • Include audit log access controls and periodic review schedules.
7. Vendor & Data Flow Specifics (Medium)
   • Require concrete contract clauses: data minimization, subprocessors list, breach notification obligations, right-to-audit, security baselines (SOC2/ISO27001 evidence), and data residency constraints.
   • Produce data flow diagrams and mapping of which data fields are shared with each vendor.
8. Operational & Administrative Controls (Medium)
   • Add break-glass / emergency access procedures with full audit trails and justification, privileged access review cadence, and separation-of-duty enforcement for admin/clinician/auditor roles.
9. Regulatory & Age/Consent Controls (Medium)
   • Add COPPA age-verification workflow if minors may use the system and explicit mapping of GDPR articles to implemented controls (legal basis, DPIA triggers).
   • Clarify consent granularity for third-party processing and exports.
10. Mobile & Client Considerations (Low-Medium)

• Specify mobile camera permission handling, local caching policies for uploaded images, encryption for local caches, and secure handling of EXIF/device metadata.

Quick prioritized next steps for the team to update requirements: - Week 1: Add Incident Response, Vulnerability Management, and Secure SDLC items into requirements backlog; define acceptance criteria. - Week 2: Add API/session security specifics, CSRF/XSS controls, token lifetimes, and logging retention policies. - Week 3: Make AI controls prescriptive (confidence thresholds, HITL for critical flags, model monitoring KPIs) and require vendor contract clauses + data flow diagrams. - Week 4: Add verifiable deletion/backups and break-glass procedures, then run a gap workshop with legal and clinical SMEs to validate compliance mapping.

If desired, I can convert the recommendations into a prioritized, issue-tracking-ready list (JIRA-friendly tickets) with exact acceptance criteria and test cases.

---

Appendix A: Original Requirements Document

Blood Test Analysis Application Requirements

We need to build a web application that allows users to upload and analyze their blood test results using AI-powered data extraction and visualization.

Key Features:

1. User Management
   - User registration and login
   - User profiles with personal details (age, gender, optional health metrics)
   - Password recovery and account management
   - User consent and privacy preferences management

2. Blood Test Uploads
   - Upload images or PDF files of blood test results
   - Support uploads from device storage
   - Direct image capture using mobile cameras
   - Include metadata such as test date and laboratory name
   - File format and quality validation
   - Upload progress and completion status

3. AI Data Extraction and Analysis
   - OCR and AI-based extraction from uploaded reports
   - Extract test names, values, units, and reference ranges
   - Identify abnormal values automatically
   - Generate easy-to-understand summaries
   - Provide explanations and contextual insights for findings

4. Health History and Visualization
   - Maintain historical record of blood test data
   - View results over time using charts and visual summaries
   - Filter data by test type or date range
   - Trend indicators showing improvement or deterioration in key health markers
   - Export data in PDF or CSV format

5. Notifications and Alerts
   - Notify users when AI analysis is complete
   - Alert users when test results fall outside normal range
   - Configurable notification preferences
   - Email and in-app notifications

The application will handle sensitive medical data and must support users managing their health information over time.

---

Appendix B: Glossary

Term	Definition
ASVS	Application Security Verification Standard (OWASP)
STRIDE	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
SAST	Static Application Security Testing
DAST	Dynamic Application Security Testing
MFA	Multi-Factor Authentication
RBAC	Role-Based Access Control
PII	Personally Identifiable Information
PHI	Protected Health Information
GDPR	General Data Protection Regulation
HIPAA	Health Insurance Portability and Accountability Act
PCI-DSS	Payment Card Industry Data Security Standard

---

Appendix C: Complete Threat List

This appendix contains the complete list of all identified threats with full descriptions and mitigation strategies. Threats are organized by risk level for easy reference.

Critical Risk Threats

THR-001 - Frontend Layer - Authentication & Password Recovery

• Category: Spoofing
• Likelihood: High | Impact: High
• Risk Level: Critical
• Description: Credential theft via phishing, reuse, or compromised local storage leading to account takeover (including abuse of password reset flows). Attackers may spoof legitimate users to access PHI and analysis results.
• Mitigation Strategy: Enforce strong password policies, rate-limit password resets, require MFA (preferably hardware or TOTP), implement phishing-resistant flows, secure session cookies (HttpOnly, Secure, SameSite=strict), avoid storing credentials in local storage, implement account lockout & notification on suspicious activity, monitor for credential stuffing and anomalous logins.

THR-004 - Edge Layer - API Gateway/WAF

• Category: Denial of Service
• Likelihood: High | Impact: High
• Risk Level: Critical
• Description: Upload flood or large-file upload spikes (accidental or malicious) causing bandwidth exhaustion or queue/backlog saturation, impacting OCR/AI worker availability and overall service.
• Mitigation Strategy: Enforce rate limits per IP/user, file size limits, upload quotas, CAPTCHA for suspicious flows, upload throttling and pre-signed upload tokens with short TTLs, autoscaling with backpressure, charge-rate limiting on heavy AI usage.

THR-006 - Application Services - Authentication & RBAC

• Category: Elevation of Privilege
• Likelihood: High | Impact: High
• Risk Level: Critical
• Description: Broken access control where users can access or modify other users’ blood test data (IDOR), or escalate to admin functions via insufficient authorization checks.
• Mitigation Strategy: Implement least-privilege RBAC with server-side authorization checks on every request, use strong resource-based ACLs, adopt attribute-based access control for sensitive operations, perform automated access control tests and code reviews, enforce separation of duties for admin functions.

THR-019 - Application Services - APIs

• Category: Information Disclosure
• Likelihood: High | Impact: High
• Risk Level: Critical
• Description: APIs exposing excessive data via verbose endpoints or misconfigured filters allow attackers to enumerate or bulk-download user PHI (insecure direct object references, over-permissive list endpoints).
• Mitigation Strategy: Implement pagination, rate limits, strict server-side authorization, field-level filtering, avoid returning full PHI in lists, require scopes for bulk export, enforce export approvals and audit before large exports.

High Risk Threats

THR-003 - Frontend Layer - File Uploads (mobile camera)

• Category: Information Disclosure
• Likelihood: High | Impact: Medium
• Risk Level: High
• Description: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-filled captions being uploaded and stored unintentionally, exposing PII/PHI.
• Mitigation Strategy: Strip EXIF/metadata on client or immediately on ingest server; present clear consent & preview showing redactions; apply automatic PII detection; educate users on metadata; minimize metadata persisted.

THR-005 - Edge Layer - TLS Termination / Gateway

• Category: Spoofing
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: TLS termination misconfiguration or acceptance of weak ciphers allows man-in-the-middle (MITM) attacks that can intercept authentication tokens or PHI in transit.
• Mitigation Strategy: Enforce TLS 1.2+ (prefer 1.3), disable weak ciphers/SSL, enable HSTS, mutual TLS for service-to-service where appropriate, certificate pinning in mobile clients, regular certificate monitoring and automated rotation.

THR-007 - Application Services - Input Handling and OCR Pipeline

• Category: Tampering
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed fonts, or OCI payloads exploit parsing libraries causing arbitrary code execution or tampering with processing results.
• Mitigation Strategy: Perform strict file type validation, sandbox processing (container isolation, seccomp), run OCR/AI tasks in isolated least-privilege environments, use up-to-date libraries, do content sanitization and enforce time/memory limits, use malware scanning for uploads.

THR-008 - Application Services - OCR/AI Integration (Third-party)

• Category: Information Disclosure
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Sensitive PHI sent to third-party AI/OCR providers without sufficient minimization or redaction leads to data exposure, provider misuse, or non-compliant processing.
• Mitigation Strategy: Minimize data sent (send redacted images or extracted text only as needed), use DPAs, choose providers with adequate certifications, implement encryption in transit and at-rest, use on-premise/self-hosted inference or private VPC endpoints where possible, apply tokenization or anonymization before sending, maintain audit trails of data shared.

THR-009 - Application Services - Analysis Results & Summaries

• Category: Tampering
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Attackers modify stored analysis results or summaries (either in transit or at rest) to change medical interpretations, causing user harm or misleading clinicians.
• Mitigation Strategy: Sign analysis outputs (digital signatures), store immutable audit logs, enforce strict RBAC for editing results, apply integrity checks and versioning, perform hashing of stored artifacts with KMS-managed keys.

THR-011 - Data Storage - Object Store (encrypted files)

• Category: Information Disclosure
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Misconfigured object storage ACLs or public buckets accidentally expose raw PHI (images/PDFs) to the internet or other tenants.
• Mitigation Strategy: Enforce private-by-default buckets, block public ACLs, use VPC endpoints, require signed URL with short TTL for access, encrypt objects with KMS, alert on ACL changes, and run periodic configuration scans.

THR-012 - Data Storage - Relational Database

• Category: Tampering
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Unauthorized modification of structured lab results, user profiles, or retention settings via SQL injection or improper DB permissions altering PHI or audit records.
• Mitigation Strategy: Use parameterized queries/ORMs, input validation, least-privilege DB accounts, separation of duties, DB activity monitoring, and regular vulnerability scanning and code review. Harden DB network access using private subnets.

THR-013 - Data Storage - Backups & Archives

• Category: Information Disclosure
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Backups containing PHI are retained beyond policy or stored unencrypted offsite, leading to data leaks during breach or vendor failure.
• Mitigation Strategy: Encrypt backups with KMS-managed keys, enforce backup retention policies, perform secure deletion/overwriting, restrict access to backup keys, and include backup verification and access logging.

THR-014 - Identity & Security Services - External IdP

• Category: Spoofing
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Compromise or misconfiguration of a federated identity provider leads to spoofed tokens, allowing unauthorized access to user accounts and PHI.
• Mitigation Strategy: Prefer enterprise-grade IdPs with strong security posture, validate tokens (signature, issuer, audience, nonce), implement token revocation and short-lived tokens, adopt SCIM provisioning controls, and monitor IdP trust relationships and metadata changes.

THR-015 - Identity & Security Services - Key Management Service (KMS)

• Category: Information Disclosure
• Likelihood: Low | Impact: High
• Risk Level: High
• Description: Compromise or mismanagement of encryption keys leads to decryption of PHI at rest and exposure of historical records and backups.
• Mitigation Strategy: Use managed KMS with HSM-backed keys, enforce strict IAM for key admins, rotate keys periodically, use envelope encryption, separate encryption duties from application admins, monitor key usage and configure key policy with least privilege.

THR-016 - Application Services - Notifications & Email/SMS Gateways

• Category: Information Disclosure
• Likelihood: High | Impact: Medium
• Risk Level: High
• Description: Notification payloads (email/SMS) contain PHI or links that leak PHI via insecure channels, interception, or if phone/email is compromised; SMS phishing risk increases if content is not carefully designed.
• Mitigation Strategy: Avoid including PHI in notifications; send minimal, non-sensitive alerts prompting app login to view results, use secure in-app notifications for PHI, offer opt-in/opt-out controls, use encrypted email if PHI must be included, and ensure vendor contracts enforce confidentiality.

THR-017 - External Services - AI/OCR Provider

• Category: Tampering
• Likelihood: Low | Impact: High
• Risk Level: High
• Description: Malicious or compromised third-party model alters extracted lab values or reference ranges, resulting in incorrect analysis or false alerts.
• Mitigation Strategy: Validate vendor outputs through sampling and test datasets, implement output validation rules and plausibility checks, keep an independent verification layer or fallback model, maintain vendor diversity, and include SLA clauses for model integrity.

THR-020 - Application Services - Input Validation (Web APIs)

• Category: Tampering
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Injection attacks (SQL, NoSQL, OS, command) via unvalidated fields (e.g., lab names, date fields, file metadata) enabling data compromise or lateral movement.
• Mitigation Strategy: Use parameterized queries or ORM, strict schema validation, input sanitization, WAF tuned for injection detection, and security-focused code reviews and fuzz testing.

THR-022 - Application Services - Audit Logging & Monitoring

• Category: Repudiation
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Insufficient, mutable, or incomplete audit logs prevent detection of malicious actions or deny accountability (e.g., missing log entries for data exports, consent changes).
• Mitigation Strategy: Implement immutable append-only logs, forward logs to a hardened SIEM, ensure logs contain user, timestamp, and context, protect log integrity with KMS-backed signing, and monitor/alert for suspicious patterns.

THR-025 - Cloud Infrastructure - IAM & Misconfiguration

• Category: Elevation of Privilege
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Over-permissive IAM roles or misconfigured cloud services permit lateral movement, privilege escalation, or data access across resources (e.g., storage read access by compute instances that shouldn’t have it).
• Mitigation Strategy: Apply least privilege, regularly audit IAM policies, use role-based access controls with separation of duties, implement resource-level policies, employ cloud configuration scanning (CSPM), and enforce ephemeral credentials for services.

THR-026 - Application Services - SSRF and SSRF to Internal Services (AI Vendor endpoints)

• Category: Tampering/Information Disclosure
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Server-side request forgery where attackers induce the backend to make requests to internal metadata, KMS endpoints, or vendor APIs to leak sensitive data or access internal services.
• Mitigation Strategy: Validate and whitelist outbound URLs, restrict outbound egress with network controls and VPC service endpoints, perform internal request authorization, and sanitize all user-controllable URLs.

THR-028 - Application Services / Data Storage - Consent & Privacy Preferences

• Category: Repudiation/Information Disclosure
• Likelihood: Medium | Impact: High
• Risk Level: High
• Description: Failure to correctly enforce user consent and privacy preferences (e.g., continued sharing to vendors after revocation) leads to non-compliant data processing and legal exposure.
• Mitigation Strategy: Store immutable consent records, check consent before any export or vendor call, provide user-facing controls and audit trails, implement consent propagation to vendors, and automate revocation enforcement with job quarantining.

Medium Risk Threats

THR-002 - Frontend Layer - Web SPA / Mobile App

• Category: Tampering
• Likelihood: Medium | Impact: Medium
• Risk Level: Medium
• Description: Client-side script manipulation (malicious browser extensions, XSS, or compromised bundle serving) that modifies UI to exfiltrate input data or change upload metadata before submission.
• Mitigation Strategy: Ensure Content Security Policy (CSP), subresource integrity (SRI) for static assets, minimize inline JS, sign mobile app builds, use code obfuscation and app attestation (e.g., SafetyNet/DeviceCheck), validate all data server-side, and protect CDN origin/integrity.

THR-010 - Application Services - Message Queue / Job Orchestration

• Category: Denial of Service
• Likelihood: Medium | Impact: Medium
• Risk Level: Medium
• Description: Job queue exhaustion or poisoning via crafted messages causing worker crashes or processing of malicious tasks, interrupting AI pipelines and delaying analyses.
• Mitigation Strategy: Authenticate and validate queued messages, set strict size and schema validation for queue payloads, use dead-letter queues, rate-limit producer APIs, throttle jobs per-user, and monitor queue lengths with alerting and autoscaling.

THR-018 - External Services - Email/SMS Provider

• Category: Repudiation
• Likelihood: Medium | Impact: Medium
• Risk Level: Medium
• Description: Insufficient logging or proof of delivery leading to disputes about whether a user was notified about critical abnormal results (non-repudiation failure).
• Mitigation Strategy: Keep signed delivery receipts, store notification audit logs with timestamps and content hashes, integrate provider webhooks for delivery status, and retain logs immutable for compliance periods.

THR-021 - Frontend & Edge - CSRF & XSS

• Category: Tampering/Information Disclosure
• Likelihood: Medium | Impact: Medium
• Risk Level: Medium
• Description: Cross-site scripting allows attackers to capture session tokens or perform actions on behalf of users; CSRF causes unauthorized actions (e.g., changing notification preferences or uploading malicious files).
• Mitigation Strategy: Use anti-CSRF tokens, SameSite cookies, strict input/output encoding, CSP, sanitize user-generated content, adopt secure frameworks and perform periodic frontend security testing.

THR-023 - Application Services - Export (PDF/CSV) Generation

• Category: Information Disclosure
• Likelihood: Medium | Impact: Medium
• Risk Level: Medium
• Description: Exports containing PHI are generated with insecure filenames or stored in locations with weak permissions, or links are shared without authentication, enabling data leakage.
• Mitigation Strategy: Require re-authentication or MFA for export, generate exports on-demand with short-lived signed URLs, sanitize filenames, restrict export storage ACLs, and log exports for audit.

THR-024 - External Services - Telemetry & Vendor Logs

• Category: Information Disclosure
• Likelihood: Medium | Impact: Medium
• Risk Level: Medium
• Description: Debugging logs, telemetry or metrics sent to third-party analytics vendors inadvertently contain PHI (e.g., test values, user IDs) and are retained by vendors.
• Mitigation Strategy: Apply strict data minimization for telemetry, scrub PHI before sending, use hashing or tokenization for identifiers, review vendor retention policies, and include DPAs restricting usage.

THR-027 - Application Services - Model & Data Poisoning

• Category: Tampering
• Likelihood: Low | Impact: Medium
• Risk Level: Medium
• Description: Attackers submit crafted reports to poison training or model adaptation pipelines (if models re-train on user data), degrading model accuracy or causing harmful inferences.
• Mitigation Strategy: Avoid using raw user data to retrain models without strong vetting, use robust training datasets, apply anomaly detection on training inputs, maintain segregated training environments, and verify model behavior after updates.

Total Threats: 28

---

Appendix D: Complete Requirements Traceability Matrix

This appendix provides complete end-to-end traceability from requirements through threats to controls and verification.

Full Traceability Table

Req ID	Requirement	Category	Sensitivity	Threat IDs	Security Controls	Priority	Verification	Status
REQ-001	User registration and login with multi-factor auth…	Authentication	Medium	THR-001, THR-005, THR-006 +7	[OWASP ASVS] V2.1, [OWASP ASVS] V2.2, [NIST SP 800-53] IA-2 +3	Critical	Review design documentation and authentication flows; test registration and login requiring MFA; attempt phishing/replay scenarios to confirm resistance; inspect configuration of MFA providers., Test login flows for privileged accounts to ensure MFA is enforced; review role definitions and access control lists to confirm coverage.	Pending
REQ-002	User profile management capturing personal details…	User Management	High	THR-001, THR-003, THR-006 +7	[ISO27001] A.18.1.4, [OWASP ASVS] V5.1, [NIST SP 800-53] PL-2 +1	Critical	Inspect sanitization procedures, verify secure deletion of test records on decommissioned media, and review backup retention/deletion logs., Review DPIAs, data inventories, and consent records; check that storage and access controls align with classifications and legal requirements.	Pending
REQ-003	User consent and privacy preferences management in…	Security & Compliance	High	THR-001, THR-004, THR-006 +7	[ISO27001] A.18.1.4, [OWASP ASVS] V11.1, [NIST SP 800-53] AU-2 +1	Critical	Review architecture documentation and data flow diagrams; test enforcement of consent in downstream processes., Review consent records, retention policies, and UI for revocation; confirm logs capture consent events and that privacy notices are available.	Pending
REQ-004	Secure upload pipeline supporting images and PDFs …	Data Ingestion	High	THR-001, THR-002, THR-003 +7	[OWASP ASVS] V5.5, [OWASP ASVS] V5.6, [NIST SP 800-53] SI-3 +1	Critical	Inspect storage architecture, test for direct access to uploaded files, and confirm isolation/sandboxing of processing components., Review upload handling code and pipeline, run tests with malformed and malicious files, and verify malware scanning integration and quarantine behavior.	Pending
REQ-005	Server-side file validation for allowed formats, s…	Data Ingestion	Medium	THR-003, THR-004, THR-007 +7	[OWASP ASVS] V5.5, [OWASP ASVS] V5.6, [NIST SP 800-53] SI-3 +1	Critical	Execute tests uploading malformed, oversized, or malicious files and verify they are rejected or quarantined; review scanner logs., Review scanning placement, test detection of known malware, and confirm update schedules for signatures.	Pending
REQ-006	Capture and store metadata for each upload includi…	Data Management	Medium	THR-001, THR-002, THR-003 +7	[OWASP ASVS] V11.6, [NIST SP 800-53] AU-3, [ISO27001] A.12.4.1	High	Inspect audit schema and stored logs, and confirm sample uploads produce complete audit records with required metadata., Verify logs contain upload metadata, review log retention settings, and sample periodic reviews for anomalies.	Pending
REQ-007	Provide upload progress, resumable uploads for lar…	User Experience	Low	THR-002, THR-003, THR-004 +7	[OWASP ASVS] V14.3, [NIST SP 800-53] CP-10, [ISO27001] A.12.3.1	High	Test chunked upload flows, simulate interrupted uploads and resume scenarios, and validate integrity checks and authentication on chunks., Inspect backup configurations and run restoration tests for upload state data; confirm procedures for resuming uploads after recovery.	Pending
REQ-008	Perform OCR and AI-based structured data extractio…	AI/ML Processing	High	THR-001, THR-002, THR-003 +7	[NIST SP 800-53] SA-9, [ISO27001] A.15.1.1, [OWASP ASVS] V13.3 +1	Critical	Review model governance artifacts and monitoring dashboards; test detection of drift and review remediation actions., Review vendor assessment reports, contracts, and data processing agreements; verify adherence in procurement records.	Pending
REQ-009	Automatically detect and flag abnormal values rela…	Clinical Decision Support	High	THR-008, THR-014, THR-017 +6	None	Medium	Manual Review	Pending
REQ-010	Generate plain-language summaries and contextual e…	Reporting & UX	Medium	THR-001, THR-009, THR-023	[OWASP ASVS] V13.3, [ISO27001] A.18.1.4, [NIST AI RMF] NIST AI RMF	High	Review examples of generated summaries for accuracy and clarity, inspect explainability metadata, and run user comprehension tests., Check display permissions for summaries, inspect content for unnecessary PII, and verify consent records where required.	Pending
REQ-011	Persist historical blood-test records with version…	Data Management	High	THR-003, THR-004, THR-007 +7	[OWASP ASVS] V11.6, [NIST SP 800-53] AU-9, [ISO27001] A.12.4.1 +1	Critical	Inspect protections on audit storage, attempt unauthorized modifications in test environment, and verify backups of audit information., Review transport encryption and logs, and validate checksum matching after transfers.	Pending
REQ-012	Provide interactive time-series visualizations and…	Visualization	Medium	THR-006, THR-008, THR-014 +4	[ISO27001] A.9.1.2, [OWASP ASVS] V5.1, [NIST SP 800-53] AC-3	High	Test access controls across roles, attempt unauthorized access to filtered data, and review access control policies., Penetration test visualization endpoints, verify server-side enforcement and attempt to retrieve data beyond user scope.	Pending
REQ-013	Allow export of selected data and reports into PDF…	Data Export	High	THR-001, THR-002, THR-003 +7	[OWASP ASVS] V5.1, [NIST SP 800-53] SC-13, [ISO27001] A.18.1.4	Critical	Verify TLS and encryption used in export delivery, check file integrity mechanisms, and test access restrictions., Review export logs and consent records; validate that exports adhere to redaction policies and legal retention rules.	Pending
REQ-014	Notify users (email and in-app) when AI analysis c…	Notifications	High	THR-001, THR-006, THR-007 +7	[NIST SP 800-53] AU-2, [ISO27001] A.13.2.1, [NIST SP 800-53] SA-9	High	Review notification logs and audit trails; test auditability of notification delivery and receipt events., Review vendor assessments and SLAs, validate secure configuration, and test notification flows for appropriate data minimization.	Pending
REQ-015	Implement configurable notification preferences (c…	User Experience	Medium	THR-001, THR-005, THR-006 +5	[NIST SP 800-53] AU-2, [OWASP ASVS] V5.1, [ISO27001] A.9.1.1	Medium	Test notification delivery respecting preferences, attempt to send unauthorised notifications, and review preference enforcement logs., Review logs for preference changes and test audit retrieval.	Pending
REQ-016	Role-based access control for users, clinicians, a…	Access Control	High	THR-001, THR-006, THR-014 +3	[NIST SP 800-53] AC-2, [NIST SP 800-53] AC-5, [OWASP ASVS] V1.2 +1	Critical	Review access control policy and records of periodic access reviews and role mappings., Conduct access control testing, attempt privilege escalation, and review authorization policies.	Pending
REQ-017	Comprehensive audit logging and monitoring of auth…	Security & Compliance	High	THR-001, THR-002, THR-003 +7	None	Medium	Manual Review	Pending
REQ-018	Encrypt all sensitive data in transit (TLS) and at…	Cryptography	High	THR-002, THR-003, THR-005 +7	[NIST SP 800-53] SC-13, [NIST SP 800-53] SC-12, [OWASP ASVS] V12.1 +1	Critical	Review cryptographic libraries and configurations, run tool-based crypto checks, and perform code audits for improper use., Review cryptography policy, enforce compliance via code reviews, and audit cryptographic usage.	Pending
REQ-019	Manage third-party integrations (AI/OCR, email/SMS…	Third-Party Risk	High	THR-002, THR-003, THR-005 +7	[ISO27001] A.15.1.1, [NIST SP 800-53] SA-12, [NIST SP 800-53] SA-9 +1	Critical	Review supply chain risk assessments, vendor attestations, and monitoring logs., Review vendor assessment artifacts, SOC reports, and procurement approvals.	Pending
REQ-020	Define data retention and deletion policies (inclu…	Data Lifecycle Management	High	THR-001, THR-002, THR-003 +7	[ISO27001] A.18.1.3, [NIST SP 800-53] MP-6, [NIST SP 800-53] CP-10 +1	Critical	Review retention schedules, deletion logs and evidence of completed deletions, and legal mapping for retention periods., Review backup configurations and run DR tests restoring datasets and verifying integrity.	Pending

Total Requirements Tracked: 20

Detailed Requirement Mappings

The following section provides detailed traceability for each requirement:

REQ-001: User registration and login with multi-factor authentication and secure password reset flows.

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-005: TLS termination misconfiguration or acceptance of weak ciphers allows man-in-the…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-009: Attackers modify stored analysis results or summaries (either in transit or at r…
• THR-012: Unauthorized modification of structured lab results, user profiles, or retention…
• …and 5 more threats

Security Controls:

• [OWASP ASVS] V2.1: [OWASP ASVS] Verify that multi-factor authentication is required for high value accounts and …
• [OWASP ASVS] V2.2: [OWASP ASVS] Verify that the application supports secure password reset and account recovery …
• [NIST SP 800-53] IA-2: [NIST SP 800-53] Identify and authenticate organizational users (or processes acting on behalf of…
• [NIST SP 800-53] IA-2 (3): [NIST SP 800-53] Use multifactor authentication for local and network access to privileged accoun…
• [ISO27001] A.9.4.2: [ISO27001] Where required by the access control policy, access to systems and applications …
• …and 1 more controls

Verification: Review design documentation and authentication flows; test registration and login requiring MFA; attempt phishing/replay scenarios to confirm resistance; inspect configuration of MFA providers., Test login flows for privileged accounts to ensure MFA is enforced; review role definitions and access control lists to confirm coverage., Review access control policy and log-on procedure documents; test implementation against policy requirements and interview administrators., Audit privileged account lists, verify MFA enforcement, and check records of privileged access assignment and reviews., Inspect password reset implementation, confirm use of time-limited tokens, review logs of reset attempts, and perform tests for token reuse, expiration, and out-of-band verification effectiveness., Review account provisioning processes, authentication logs, and test that only authenticated identities gain access; examine identity proofing records.

Priority: Critical | Status: Pending

---

REQ-002: User profile management capturing personal details (age, gender) and optional health metrics with ed…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-009: Attackers modify stored analysis results or summaries (either in transit or at r…
• THR-012: Unauthorized modification of structured lab results, user profiles, or retention…
• …and 5 more threats

Security Controls:

• [ISO27001] A.18.1.4: [ISO27001] Privacy and protection of personally identifiable information should be ensured …
• [OWASP ASVS] V5.1: [OWASP ASVS] Verify that privacy requirements are implemented (data minimization, purpose lim…
• [NIST SP 800-53] PL-2: [NIST SP 800-53] Develop, document, and disseminate system security plans and privacy impact asse…
• [NIST SP 800-53] MP-6: [NIST SP 800-53] Sanitize or destroy system media containing sensitive information before disposa…

Verification: Inspect sanitization procedures, verify secure deletion of test records on decommissioned media, and review backup retention/deletion logs., Review DPIAs, data inventories, and consent records; check that storage and access controls align with classifications and legal requirements., Review data collection forms and APIs for unnecessary fields; test authorization controls for viewing/editing profiles; review privacy policy and UI for user controls., Review system security plan and PIA documents; confirm controls from plan are implemented in system and tested.

Priority: Critical | Status: Pending

---

REQ-003: User consent and privacy preferences management including recording consent, purpose, timestamp, and…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-004: Upload flood or large-file upload spikes (accidental or malicious) causing bandw…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-009: Attackers modify stored analysis results or summaries (either in transit or at r…
• THR-012: Unauthorized modification of structured lab results, user profiles, or retention…
• …and 5 more threats

Security Controls:

• [ISO27001] A.18.1.4: [ISO27001] Privacy and protection of personally identifiable information should be ensured …
• [OWASP ASVS] V11.1: [OWASP ASVS] Verify that all relevant user consent actions are logged with sufficient detail …
• [NIST SP 800-53] AU-2: [NIST SP 800-53] Determine which events are to be audited and logged to provide accountability an…
• [NIST SP 800-53] PL-8: [NIST SP 800-53] Document privacy requirements and ensure the system architecture supports consen…

Verification: Review architecture documentation and data flow diagrams; test enforcement of consent in downstream processes., Review consent records, retention policies, and UI for revocation; confirm logs capture consent events and that privacy notices are available., Inspect consent logs, verify immutability or tamper-evidence, and test retrieval for audit scenarios., Review audit event definitions and confirm system emits and stores consent events; perform audit log retrieval tests.

Priority: Critical | Status: Pending

---

REQ-004: Secure upload pipeline supporting images and PDFs from device storage and direct camera capture on m…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-004: Upload flood or large-file upload spikes (accidental or malicious) causing bandw…
• THR-007: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed …
• …and 5 more threats

Security Controls:

• [OWASP ASVS] V5.5: [OWASP ASVS] Verify that uploaded files are validated for type, size and content, that danger…
• [OWASP ASVS] V5.6: [OWASP ASVS] Verify that file uploads are handled in a secure pipeline (isolation, storage ou…
• [NIST SP 800-53] SI-3: [NIST SP 800-53] Employ mechanisms that detect and protect against malicious code at appropriate …
• [ISO27001] A.12.2.1: [ISO27001] Information systems should be protected against malware and appropriate detectio…

Verification: Inspect storage architecture, test for direct access to uploaded files, and confirm isolation/sandboxing of processing components., Review upload handling code and pipeline, run tests with malformed and malicious files, and verify malware scanning integration and quarantine behavior., Review malware controls, patch and AV reports, and test recovery procedures with simulated infections., Validate malware scanning coverage, run known-malicious sample tests, and review incident response for malware detection events.

Priority: Critical | Status: Pending

---

REQ-005: Server-side file validation for allowed formats, size limits, image quality heuristics (resolution, …

Related Threats:

• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-004: Upload flood or large-file upload spikes (accidental or malicious) causing bandw…
• THR-007: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed …
• THR-008: Sensitive PHI sent to third-party AI/OCR providers without sufficient minimizati…
• THR-011: Misconfigured object storage ACLs or public buckets accidentally expose raw PHI …
• …and 5 more threats

Security Controls:

• [OWASP ASVS] V5.5: [OWASP ASVS] Verify that uploaded files are validated for type, size and content, that danger…
• [OWASP ASVS] V5.6: [OWASP ASVS] Verify that file uploads are handled in a secure pipeline (isolation, storage ou…
• [NIST SP 800-53] SI-3: [NIST SP 800-53] Employ mechanisms that detect and protect against malicious code at appropriate …
• [NIST SP 800-53] SC-12: [NIST SP 800-53] Implement cryptographic mechanisms to protect data in transit and at rest (usefu…

Verification: Execute tests uploading malformed, oversized, or malicious files and verify they are rejected or quarantined; review scanner logs., Review scanning placement, test detection of known malware, and confirm update schedules for signatures., Inspect storage locations, test direct URL access, and review content inspection logs and processing workflows., Verify TLS configuration, check encryption-at-rest usage, and review key management policies and logs.

Priority: Critical | Status: Pending

---

REQ-006: Capture and store metadata for each upload including test date, laboratory name, device/time metadat…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-004: Upload flood or large-file upload spikes (accidental or malicious) causing bandw…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• …and 5 more threats

Security Controls:

• [OWASP ASVS] V11.6: [OWASP ASVS] Verify that uploads and file handling actions are logged with sufficient metadat…
• [NIST SP 800-53] AU-3: [NIST SP 800-53] Audit records should contain sufficient information to establish what events occ…
• [ISO27001] A.12.4.1: [ISO27001] Event logs recording user activities, exceptions, faults and information securit…

Verification: Inspect audit schema and stored logs, and confirm sample uploads produce complete audit records with required metadata., Verify logs contain upload metadata, review log retention settings, and sample periodic reviews for anomalies., Review sample upload records and logs to confirm metadata presence and linkage; test tamper attempts to metadata and review provenance trails.

Priority: High | Status: Pending

---

REQ-007: Provide upload progress, resumable uploads for large files or unreliable networks, and clear complet…

Related Threats:

• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-004: Upload flood or large-file upload spikes (accidental or malicious) causing bandw…
• THR-007: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed …
• THR-008: Sensitive PHI sent to third-party AI/OCR providers without sufficient minimizati…
• …and 5 more threats

Security Controls:

• [OWASP ASVS] V14.3: [OWASP ASVS] Verify that APIs support resumable and chunked uploads with integrity checks and…
• [NIST SP 800-53] CP-10: [NIST SP 800-53] Implement backups and recovery mechanisms to ensure reliable completion of criti…
• [ISO27001] A.12.3.1: [ISO27001] Backup copies of information, software, and systems necessary for business conti…

Verification: Test chunked upload flows, simulate interrupted uploads and resume scenarios, and validate integrity checks and authentication on chunks., Inspect backup configurations and run restoration tests for upload state data; confirm procedures for resuming uploads after recovery., Review backup and recovery plans, test recovery of interrupted uploads, and validate upload state persistence across failures.

Priority: High | Status: Pending

---

REQ-008: Perform OCR and AI-based structured data extraction to identify test names, result values, units, an…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-007: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed …
• …and 5 more threats

Security Controls:

• [NIST SP 800-53] SA-9: [NIST SP 800-53] Ensure that external system services (e.g., AI/OCR vendors) are assessed for sec…
• [ISO27001] A.15.1.1: [ISO27001] Information security requirements for mitigating the risks associated with suppl…
• [OWASP ASVS] V13.3: [OWASP ASVS] Verify that AI and algorithmic processing includes validation, bias checks, conf…
• [NIST AI RMF] NIST AI RMF: [NIST AI RMF] Establish processes for model assessment, monitoring, and governance (note: incl…

Verification: Review model governance artifacts and monitoring dashboards; test detection of drift and review remediation actions., Review vendor assessment reports, contracts, and data processing agreements; verify adherence in procurement records., Inspect supplier contracts for security clauses, review supplier audit results, and confirm monitoring activities., Review model validation reports, run accuracy tests on representative datasets, and verify presence of confidence scores and explainability metadata in outputs.

Priority: Critical | Status: Pending

---

REQ-009: Automatically detect and flag abnormal values relative to reference ranges and user-specific factors…

Related Threats:

• THR-008: Sensitive PHI sent to third-party AI/OCR providers without sufficient minimizati…
• THR-014: Compromise or misconfiguration of a federated identity provider leads to spoofed…
• THR-017: Malicious or compromised third-party model alters extracted lab values or refere…
• THR-018: Insufficient logging or proof of delivery leading to disputes about whether a us…
• THR-019: APIs exposing excessive data via verbose endpoints or misconfigured filters allo…
• …and 4 more threats

Verification: Manual Review

Priority: Medium | Status: Pending

---

REQ-010: Generate plain-language summaries and contextual explanations for findings, including limitations, c…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-009: Attackers modify stored analysis results or summaries (either in transit or at r…
• THR-023: Exports containing PHI are generated with insecure filenames or stored in locati…

Security Controls:

• [OWASP ASVS] V13.3: [OWASP ASVS] Verify that AI and algorithmic processing includes validation, bias checks, conf…
• [ISO27001] A.18.1.4: [ISO27001] Privacy and protection of personally identifiable information should be ensured …
• [NIST AI RMF] NIST AI RMF: [NIST AI RMF] AI systems should provide explanations for outputs appropriate to the audience a…

Verification: Review examples of generated summaries for accuracy and clarity, inspect explainability metadata, and run user comprehension tests., Check display permissions for summaries, inspect content for unnecessary PII, and verify consent records where required., Review explanation templates for different roles, test user comprehension, and validate that metadata about source data and confidence is available.

Priority: High | Status: Pending

---

REQ-011: Persist historical blood-test records with versioning, provenance (which file and extraction version…

Related Threats:

• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-004: Upload flood or large-file upload spikes (accidental or malicious) causing bandw…
• THR-007: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed …
• THR-011: Misconfigured object storage ACLs or public buckets accidentally expose raw PHI …
• THR-012: Unauthorized modification of structured lab results, user profiles, or retention…
• …and 5 more threats

Security Controls:

• [OWASP ASVS] V11.6: [OWASP ASVS] Verify that uploads and file handling actions are logged with sufficient metadat…
• [NIST SP 800-53] AU-9: [NIST SP 800-53] Protect audit information and tools from unauthorized access, modification, and …
• [ISO27001] A.12.4.1: [ISO27001] Event logs recording user activities, exceptions, faults and information securit…
• [NIST SP 800-53] MP-5: [NIST SP 800-53] Employ protections for media during transport to preserve integrity and provenan…

Verification: Inspect protections on audit storage, attempt unauthorized modifications in test environment, and verify backups of audit information., Review transport encryption and logs, and validate checksum matching after transfers., Review version histories and audit logs for completeness, verify checksums and metadata linkage, and test tamper attempts., Review logs for version events, inspect retention policies, and confirm periodic log reviews occurred.

Priority: Critical | Status: Pending

---

REQ-012: Provide interactive time-series visualizations and charts with filtering by test type, date range, a…

Related Threats:

• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-008: Sensitive PHI sent to third-party AI/OCR providers without sufficient minimizati…
• THR-014: Compromise or misconfiguration of a federated identity provider leads to spoofed…
• THR-017: Malicious or compromised third-party model alters extracted lab values or refere…
• THR-018: Insufficient logging or proof of delivery leading to disputes about whether a us…
• …and 2 more threats

Security Controls:

• [ISO27001] A.9.1.2: [ISO27001] Users should only be provided access to the network and services that they are a…
• [OWASP ASVS] V5.1: [OWASP ASVS] Verify that privacy requirements are implemented (data minimization, purpose lim…
• [NIST SP 800-53] AC-3: [NIST SP 800-53] Enforce approved authorizations for logical access to information and system res…

Verification: Test access controls across roles, attempt unauthorized access to filtered data, and review access control policies., Penetration test visualization endpoints, verify server-side enforcement and attempt to retrieve data beyond user scope., Inspect queries serving visualizations for permission checks, run tests for unauthorized filter combinations, and review privacy constraints.

Priority: High | Status: Pending

---

REQ-013: Allow export of selected data and reports into PDF and CSV formats, enforce redaction rules based on…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-005: TLS termination misconfiguration or acceptance of weak ciphers allows man-in-the…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• …and 5 more threats

Security Controls:

• [OWASP ASVS] V5.1: [OWASP ASVS] Verify that privacy requirements are implemented (data minimization, purpose lim…
• [NIST SP 800-53] SC-13: [NIST SP 800-53] Use cryptographic mechanisms to protect the confidentiality and integrity of inf…
• [ISO27001] A.18.1.4: [ISO27001] Privacy and protection of personally identifiable information should be ensured …

Verification: Verify TLS and encryption used in export delivery, check file integrity mechanisms, and test access restrictions., Review export logs and consent records; validate that exports adhere to redaction policies and legal retention rules., Attempt data exports with and without consent, inspect exported files for proper redaction, and review export audit logs.

Priority: Critical | Status: Pending

---

REQ-014: Notify users (email and in-app) when AI analysis completes and when results are outside normal range…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-007: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed …
• THR-009: Attackers modify stored analysis results or summaries (either in transit or at r…
• THR-012: Unauthorized modification of structured lab results, user profiles, or retention…
• …and 5 more threats

Security Controls:

• [NIST SP 800-53] AU-2: [NIST SP 800-53] Determine which events are to be audited and logged to provide accountability an…
• [ISO27001] A.13.2.1: [ISO27001] Responsibilities and procedures for information transfer should be established t…
• [NIST SP 800-53] SA-9: [NIST SP 800-53] Ensure that external system services (e.g., AI/OCR vendors, email gateways) are …

Verification: Review notification logs and audit trails; test auditability of notification delivery and receipt events., Review vendor assessments and SLAs, validate secure configuration, and test notification flows for appropriate data minimization., Review procedures, test email gateway TLS and configuration, and confirm notification content minimization.

Priority: High | Status: Pending

---

REQ-015: Implement configurable notification preferences (channels, thresholds, frequency) and allow users to…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-005: TLS termination misconfiguration or acceptance of weak ciphers allows man-in-the…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-014: Compromise or misconfiguration of a federated identity provider leads to spoofed…
• THR-016: Notification payloads (email/SMS) contain PHI or links that leak PHI via insecur…
• …and 3 more threats

Security Controls:

• [NIST SP 800-53] AU-2: [NIST SP 800-53] Determine which events are to be audited and logged to provide accountability an…
• [OWASP ASVS] V5.1: [OWASP ASVS] Verify that privacy requirements are implemented (data minimization, purpose lim…
• [ISO27001] A.9.1.1: [ISO27001] An access control policy should be established, based on business and security r…

Verification: Test notification delivery respecting preferences, attempt to send unauthorised notifications, and review preference enforcement logs., Review logs for preference changes and test audit retrieval., Review access control policy and test role restrictions on changing escalation settings.

Priority: Medium | Status: Pending

---

REQ-016: Role-based access control for users, clinicians, administrators, and auditors; principle of least pr…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-014: Compromise or misconfiguration of a federated identity provider leads to spoofed…
• THR-022: Insufficient, mutable, or incomplete audit logs prevent detection of malicious a…
• THR-025: Over-permissive IAM roles or misconfigured cloud services permit lateral movemen…
• …and 1 more threats

Security Controls:

• [NIST SP 800-53] AC-2: [NIST SP 800-53] Manage information system accounts, including account creation, enabling, disabl…
• [NIST SP 800-53] AC-5: [NIST SP 800-53] Divide responsibilities and duties among different individuals to reduce the ris…
• [OWASP ASVS] V1.2: [OWASP ASVS] Verify that authentication and authorization controls are enforced server-side a…
• [ISO27001] A.9.1.1: [ISO27001] An access control policy should be established, based on business and security r…

Verification: Review access control policy and records of periodic access reviews and role mappings., Conduct access control testing, attempt privilege escalation, and review authorization policies., Review role definitions, test that separation is enforced, and examine change logs for segregation adherence., Review account lifecycle processes, test creation and removal flows, and sample account statuses.

Priority: Critical | Status: Pending

---

REQ-017: Comprehensive audit logging and monitoring of authentication events, data access, uploads, edits, ex…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-005: TLS termination misconfiguration or acceptance of weak ciphers allows man-in-the…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• …and 5 more threats

Verification: Manual Review

Priority: Medium | Status: Pending

---

REQ-018: Encrypt all sensitive data in transit (TLS) and at rest (AES-256 or equivalent), with secure key man…

Related Threats:

• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-005: TLS termination misconfiguration or acceptance of weak ciphers allows man-in-the…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-008: Sensitive PHI sent to third-party AI/OCR providers without sufficient minimizati…
• …and 5 more threats

Security Controls:

• [NIST SP 800-53] SC-13: [NIST SP 800-53] Employ cryptographic mechanisms to protect the confidentiality and integrity of …
• [NIST SP 800-53] SC-12: [NIST SP 800-53] Implement cryptographic mechanisms to protect data in transit and at rest (usefu…
• [OWASP ASVS] V12.1: [OWASP ASVS] Verify that strong, industry-accepted cryptographic algorithms and correct imple…
• [ISO27001] A.10.1.1: [ISO27001] A policy on the use of cryptographic controls should be developed and implemente…

Verification: Review cryptographic libraries and configurations, run tool-based crypto checks, and perform code audits for improper use., Review cryptography policy, enforce compliance via code reviews, and audit cryptographic usage., Review TLS configurations, verify encryption-at-rest settings and key management logs, and perform cryptographic policy reviews., Inspect KMS configurations, key usage logs, rotation schedules, and access control policies.

Priority: Critical | Status: Pending

---

REQ-019: Manage third-party integrations (AI/OCR, email/SMS gateways, cloud storage) with vendor risk assessm…

Related Threats:

• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-005: TLS termination misconfiguration or acceptance of weak ciphers allows man-in-the…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-007: Maliciously crafted files (images, PDFs) containing embedded scripts, malformed …
• …and 5 more threats

Security Controls:

• [ISO27001] A.15.1.1: [ISO27001] Information security requirements for mitigating the risks associated with suppl…
• [NIST SP 800-53] SA-12: [NIST SP 800-53] Ensure that supply chain protections are in place for externally provided servic…
• [NIST SP 800-53] SA-9: [NIST SP 800-53] Ensure that external system services (e.g., AI/OCR vendors) are assessed for sec…
• [OWASP ASVS] V13.3: [OWASP ASVS] Verify that AI and algorithmic processing includes validation, bias checks, conf…

Verification: Review supply chain risk assessments, vendor attestations, and monitoring logs., Review vendor assessment artifacts, SOC reports, and procurement approvals., Review vendor-provided model validation reports and test sample outputs for compliance., Review supplier contracts and DPAs, check assessment evidence, and confirm adherence to SLAs.

Priority: Critical | Status: Pending

---

REQ-020: Define data retention and deletion policies (including right-to-be-forgotten), automated backups, cr…

Related Threats:

• THR-001: Credential theft via phishing, reuse, or compromised local storage leading to ac…
• THR-002: Client-side script manipulation (malicious browser extensions, XSS, or compromis…
• THR-003: Sensitive PHI embedded in image EXIF metadata (location, device info) or auto-fi…
• THR-006: Broken access control where users can access or modify other users’ blood test d…
• THR-008: Sensitive PHI sent to third-party AI/OCR providers without sufficient minimizati…
• …and 5 more threats

Security Controls:

• [ISO27001] A.18.1.3: [ISO27001] Records should be protected to ensure they remain available and accurate over th…
• [NIST SP 800-53] MP-6: [NIST SP 800-53] Sanitize or destroy system media containing sensitive information before disposa…
• [NIST SP 800-53] CP-10: [NIST SP 800-53] Implement backups and recovery mechanisms to ensure reliable completion of criti…
• [OWASP ASVS] V11.6: [OWASP ASVS] Verify that uploads and file handling actions are logged with sufficient metadat…

Verification: Review retention schedules, deletion logs and evidence of completed deletions, and legal mapping for retention periods., Review backup configurations and run DR tests restoring datasets and verifying integrity., Inspect sanitization procedures and logs, and test secure deletion on sample media., Inspect deletion logs and snapshots, verify audit entries for right-to-be-forgotten operations, and test recovery scenarios.

Priority: Critical | Status: Pending

---

---

Appendix E: References

• OWASP ASVS 5.0
• NIST Cybersecurity Framework
• ISO/IEC 27001:2022
• OWASP Top 10
• MITRE ATT&CK Framework

---

End of Report - Generated by Security Requirements Analysis System v2.0 Generated: 2025-11-19 13:38:03